Маркетинг @ Анализаторы исходного кода

По роду своей деятельности в последнее время сталкиваюсь с различными текстами, в которых прямо или с намеками обсуждаются преимущества тех или иных продуктов или подходов над другими. Речь идет о задаче статического анализа исходного кода с целью поиска недостатков, снижающих защищенность программного продукта (т.е. речь не идет о недостатках качества кода в общем смысле слова).

Так как я человек впечатлительный и легко поддающийся на троллинг, решил написать своё ответное мнение в серии постов на тему «Типичный булшит в якобы аналитических заметках про технологии анализа исходного кода».

Итак, сегодня — первая серия, и поговорим мы вот про какие заявления (встречаются в произвольной комбинации): «сигнатурный анализ не может обеспечить полноту», «сигнатурный анализ дает много ложных срабатываний», «сигнатурный анализ хуже, чем анализ потоков данных», «анализ потоков данных дает офигительную полноту при низком числе ложных срабатываний», «о какой полноте может идти речь при наличии в базе N сигнатур» и вот это вот всё.

Для тех, кто испугался объема, сразу выводы:

1. Все применяемые сейчас вида анализа кода — сигнатурные (в т.ч. taint анализ на основе потоков данных).

2. В свете п.1. сравнивать подходы и продукты по количеству сигнатур — нонсенс. Сигнатура может описывать как целый класс недостатков (например, input validation), так и один-единственный экземпляр (unserialize($_GET[.*])).

3. Про полноту и точность можно говорить только после фиксирования класса недостатков (например, input validation). Полноты «вообще» — не существует. В свете разговора про каждый класс недостатков на первое место выходит формальная модель описания недостатка. По факту, сейчас почти всегда используется модель невмешательства (aka taint). Данная модель описывает только уязвимости класса input validation. Она бесполезна для недостатков авторизации. Полнота, говорите?

4. Даже в рамках одного класса недостатков, например, input validation, существующая модель невмешательства не может обеспечить не только полноту, но и даже приемлемую точность. Ограничения модели невмешательства расписаны вот тут (англ).

Наука, инновации, статический анализ и РусКрипто 2013

В этом году на горячо любимой мной конференции РусКрипто впервые за ее историю состоится отдельная секция по анализу кода — «Анализ кода и технологии защиты: динамический и статистический анализ, виртуализация кода, исследование на недекларированные возможности».

Судя по аннотациям докладов, ожидаются как выступления с научными результатами, так и с передачей опыта или суммы знаний по конкретным задачам предметной области (мои любимые типы докладов).

А вот и расширенная аннотация моего доклада.

Taint Analysis: ограничения модели. Часть 1.

Недавно мы рассмотрели две модели уязвимостей, которые используются при статическом и динамическом анализе веб-приложений. В предыдущем посте было показано, что обнаружение уязвимостей не будет эффективно на 100%, если у используемой модели есть ограничения. Именно об ограничениях taint-анализа и пойдет сегодня речь. Мы рассмотрим, какие типы уязвимостей заведомо не могут быть найдены при использовании этой модели.

Обнаружение уязвимостей: рассуждение о полноте и точности

В предыдущем посте мы рассмотрели две модели уязвимостей, которые используются при статическом и динамическом анализе веб-приложений.
При выборе инструмента для поиска уязвимостей внимание обычно обращают (помимо цены) на две характеристики: на полноту и на точность обнаружения. В этом посте я бы хотел порассуждать как раз на эту тему.

Модели уязвимостей, используемые в статическом и динамическом анализе

В предыдущем посте я вкратце рассказал об особенностях статического и динамического анализа в контексте проверки свойств программы. Одно из возможных свойств — это наличие или отсутствие уязвимостей¹.
Возникает вопрос, как переформулировать классическое определение уязвимости (свойство, позволяющее нарушить конфиденциальность, целостность или доступность информационных ресурсов ) в терминах представлений программы (см. предыдущий пост)? Давайте попробуем разобраться.