Pull to refresh

Comments 18

И ведь найти эту ошибку самому практически невозможно: в режиме отладки вызов memset работает нормально.


Обычно те, кто пишет код криптографических алгоритмов уже знают об этом и вызывают эту функцию через volatile указатель :) А как вы определяете, что массив это действительно sensitive data, а не обычный массив? По названию переменной?

Мне кажется мемсет нулями в область памяти которая потом не используется.

Обычно те, кто пишет код криптографических алгоритмов уже знают об этом и вызывают эту функцию через volatile указатель :)
Ох, если бы. Эта ошибка живёт практически везде. Кстати, не стоит полагаться в этом на volatile. Я не могу доказать, но есть подозрение, что это ненадёжно. Функция то принимает просто void *, что может привести не к тому поведению, которое хотелось.

А как вы определяете, что массив это действительно sensitive data, а не обычный массив? По названию переменной?
А никак. Это не требуется. Если что-то чистят и не использую, это явно приватные данные. Т.е. конечно это может быть просто неинтересный массив, который почём зря чистят в самом конце, но на практике такого не бывает. Вот сколько раз срабатывала V597, столько и ошибок. Я не припомню ложных срабатываний.
Надо же, на hackerone.com есть даже Qiwi.
Кстати о Киви.
Однажды завел у них виртуальную кредитку и не мог платить через нее. Через час догадался в чем проблема.
Спросил у одного кивиста как продать им их же баг, из-за которого я не мог делать платежи. Он отослал к другому. Другой сказал, что это не профиль его отдела и они покупают только дыры в безопасности.
На этом все. Такой «командный дух» у кивистов.
А можно вопрос от гуманитария? то бишь от меня.
И ответить на него прошу, если это возможно, «гуманитарным» языком :)

Вопрос вот о чем: с одной стороны, найти ошибки, конечно, ваш анализатор какие-то находит. Где-то выявятся неэкранированные формы, или какие-то граничные случаи вылезут, где-то просто баг в программе который нарушит функциональность. Но вот точно ли эти баги можно использовать именно для нарушения безопасности системы? Типа того, что подать в программу какие-то данные, которые позволят исполнить произвольные команды в система с правами уязвимой программы. Очевидно, как раз это та самая часть, которую надо копать именно человеческим мозгом, а ваш анализатор даст просто намёк что «вот тут скорее всего может быть дыра».

А вопрос-предложение вот в чем: есть довольно известные уязвимости, которые бомбанули в интернете в прошлом: я помню, какие-то версии proftpd были дырявыми, потом история с openssl, потом с гитом, и тд и тп.
А можете вы написать статью, которая покажет как именно ваш анализатор мог бы обнаружить именно эти уязвимости? Не просто ошибки, а что-то вроде «как можно было предотвратить CVE-2014-9390». Это было бы интересно, имхо.
Конечно, если ваш софт умеет работать с тем языком программирования на котором написаны уязвимые сервисы.

Более ужасной и примитивной рекламы pvs-studio я еще не видел. Что, так плохо все с продажей лицензий, что решились поиграть на почве людской лени и жадности типа " купите лицензию и будете в шоколаде, а мы расскажем как". Мне кажется, что это не тот ресурс, где можно так играть на примитивах, или я ошибаюсь и Хабр становится "IT-одноглазники"?

Эм, а зачем покупать? Тут более чем достаточно способа с комментарием.

"Бесплатная лицензия не распространяется на зеркала проектов" — вот тут проблемка, откуда у меня возьмется доступ к основному репозиторию проекта (если речь о bug bounty)? А с форком не прокатит ведь, верно?

Всегда хочется найти повод, чтобы оправдать бездействие. Не выйдет :). Держите:

Name: symbix
Key: KRA0-4XH6-1K7G-SUG6
License Type: Team9 License up to 9 developers
License Valid Thru: Sep 24, 2019

Будет мало — приходите, ещё сгенерирую.
Легкий способ заработка в интернете без вложений ;)
Не хватает картинки с подростком и кучей денег.
image
Да, с помощью него можно проверить два, три, четыре проекта за вечер — но это еще не всё.

Зависит от размера проекта. А если учесть что PVS Studio выдает газиллионы ложных сообщений, которые при ручной тщательной проверке оказываются и не ошибками вовсе (или просто ложными) — то о скорости проверки можно забыть, потому что каждое сообщение нужно «помыть и завернуть», причём зачастую для этого требуется ощутимое время.

Нельзя просто взять и найти уязвимость с помощью анализатора — для этого нужно хорошо знать не только язык, но и кодовую базу проекта, без этого можно разве что банальные отсутствия проверок на null или повторяющиеся условия выловить.
Про ложные срабатывания. Любой статический анализ требует предварительной настройки. И да, конечно, если взять проект размера Chromium, то его хватит не на день, а на месяц :). Я в процессе последней поверхностной проверки в 2018 году написал про него цикл из 7 статей: 1, 2, 3, 4, 5, 6, 7.

Да, найти уязвимость непросто. Только очень маленькое количество ошибок представляет собой угрозу. Однако, без статического анализа начать их искать ещё сложнее. За что зацепиться? С чего начать? Статический анализатор подбрасывает информацию (дефектный код) для дальнейшего изучения и исследования.
Если бы вы сами находили уязвимости и зарабатывали на этом, то не хотели бы конкурентов в лице нас, не так ли?
Нет, нет, это не наше. Мы продаём лопаты. :)
Only those users with full accounts are able to leave comments. Log in, please.