Comments 18
И ведь найти эту ошибку самому практически невозможно: в режиме отладки вызов memset работает нормально.
Обычно те, кто пишет код криптографических алгоритмов уже знают об этом и вызывают эту функцию через volatile указатель :) А как вы определяете, что массив это действительно sensitive data, а не обычный массив? По названию переменной?
Мне кажется мемсет нулями в область памяти которая потом не используется.
Обычно те, кто пишет код криптографических алгоритмов уже знают об этом и вызывают эту функцию через volatile указатель :)Ох, если бы. Эта ошибка живёт практически везде. Кстати, не стоит полагаться в этом на volatile. Я не могу доказать, но есть подозрение, что это ненадёжно. Функция то принимает просто void *, что может привести не к тому поведению, которое хотелось.
А как вы определяете, что массив это действительно sensitive data, а не обычный массив? По названию переменной?А никак. Это не требуется. Если что-то чистят и не использую, это явно приватные данные. Т.е. конечно это может быть просто неинтересный массив, который почём зря чистят в самом конце, но на практике такого не бывает. Вот сколько раз срабатывала V597, столько и ошибок. Я не припомню ложных срабатываний.
Надо же, на hackerone.com есть даже Qiwi.
Кстати о Киви.
Однажды завел у них виртуальную кредитку и не мог платить через нее. Через час догадался в чем проблема.
Спросил у одного кивиста как продать им их же баг, из-за которого я не мог делать платежи. Он отослал к другому. Другой сказал, что это не профиль его отдела и они покупают только дыры в безопасности.
На этом все. Такой «командный дух» у кивистов.
Кстати о Киви.
Однажды завел у них виртуальную кредитку и не мог платить через нее. Через час догадался в чем проблема.
Спросил у одного кивиста как продать им их же баг, из-за которого я не мог делать платежи. Он отослал к другому. Другой сказал, что это не профиль его отдела и они покупают только дыры в безопасности.
На этом все. Такой «командный дух» у кивистов.
Ждем поддержки Go lang.
А можно вопрос от гуманитария? то бишь от меня.
И ответить на него прошу, если это возможно, «гуманитарным» языком :)
Вопрос вот о чем: с одной стороны, найти ошибки, конечно, ваш анализатор какие-то находит. Где-то выявятся неэкранированные формы, или какие-то граничные случаи вылезут, где-то просто баг в программе который нарушит функциональность. Но вот точно ли эти баги можно использовать именно для нарушения безопасности системы? Типа того, что подать в программу какие-то данные, которые позволят исполнить произвольные команды в система с правами уязвимой программы. Очевидно, как раз это та самая часть, которую надо копать именно человеческим мозгом, а ваш анализатор даст просто намёк что «вот тут скорее всего может быть дыра».
А вопрос-предложение вот в чем: есть довольно известные уязвимости, которые бомбанули в интернете в прошлом: я помню, какие-то версии proftpd были дырявыми, потом история с openssl, потом с гитом, и тд и тп.
А можете вы написать статью, которая покажет как именно ваш анализатор мог бы обнаружить именно эти уязвимости? Не просто ошибки, а что-то вроде «как можно было предотвратить CVE-2014-9390». Это было бы интересно, имхо.
Конечно, если ваш софт умеет работать с тем языком программирования на котором написаны уязвимые сервисы.
И ответить на него прошу, если это возможно, «гуманитарным» языком :)
Вопрос вот о чем: с одной стороны, найти ошибки, конечно, ваш анализатор какие-то находит. Где-то выявятся неэкранированные формы, или какие-то граничные случаи вылезут, где-то просто баг в программе который нарушит функциональность. Но вот точно ли эти баги можно использовать именно для нарушения безопасности системы? Типа того, что подать в программу какие-то данные, которые позволят исполнить произвольные команды в система с правами уязвимой программы. Очевидно, как раз это та самая часть, которую надо копать именно человеческим мозгом, а ваш анализатор даст просто намёк что «вот тут скорее всего может быть дыра».
А вопрос-предложение вот в чем: есть довольно известные уязвимости, которые бомбанули в интернете в прошлом: я помню, какие-то версии proftpd были дырявыми, потом история с openssl, потом с гитом, и тд и тп.
А можете вы написать статью, которая покажет как именно ваш анализатор мог бы обнаружить именно эти уязвимости? Не просто ошибки, а что-то вроде «как можно было предотвратить CVE-2014-9390». Это было бы интересно, имхо.
Конечно, если ваш софт умеет работать с тем языком программирования на котором написаны уязвимые сервисы.
Вот статья на эту тему: "Как PVS-Studio может помочь в поиске уязвимостей?". В ней есть примеры, что анализатор мог бы выявить некоторые из известных уязвимость (если бы его использовали :).
UFO just landed and posted this here
Легкий способ заработка в интернете без вложений ;)
Не хватает картинки с подростком и кучей денег.
Да, с помощью него можно проверить два, три, четыре проекта за вечер — но это еще не всё.
Зависит от размера проекта. А если учесть что PVS Studio выдает газиллионы ложных сообщений, которые при ручной тщательной проверке оказываются и не ошибками вовсе (или просто ложными) — то о скорости проверки можно забыть, потому что каждое сообщение нужно «помыть и завернуть», причём зачастую для этого требуется ощутимое время.
Нельзя просто взять и найти уязвимость с помощью анализатора — для этого нужно хорошо знать не только язык, но и кодовую базу проекта, без этого можно разве что банальные отсутствия проверок на null или повторяющиеся условия выловить.
Про ложные срабатывания. Любой статический анализ требует предварительной настройки. И да, конечно, если взять проект размера Chromium, то его хватит не на день, а на месяц :). Я в процессе последней поверхностной проверки в 2018 году написал про него цикл из 7 статей: 1, 2, 3, 4, 5, 6, 7.
Да, найти уязвимость непросто. Только очень маленькое количество ошибок представляет собой угрозу. Однако, без статического анализа начать их искать ещё сложнее. За что зацепиться? С чего начать? Статический анализатор подбрасывает информацию (дефектный код) для дальнейшего изучения и исследования.
Да, найти уязвимость непросто. Только очень маленькое количество ошибок представляет собой угрозу. Однако, без статического анализа начать их искать ещё сложнее. За что зацепиться? С чего начать? Статический анализатор подбрасывает информацию (дефектный код) для дальнейшего изучения и исследования.
Если бы вы сами находили уязвимости и зарабатывали на этом, то не хотели бы конкурентов в лице нас, не так ли?
Sign up to leave a comment.
Легкий способ заработать на Bug Bounty