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

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

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

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

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

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

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

К типичным недостаткам относятся недостатки, возникающие вследствие некорректного использование какого-либо известного API, функций стандартной библиотеки, конструкций языка и т.д. Примерами типичных недостатков являются различные переполнения, уязвимости форматной строки, разыменование нулевого указателя, возможность внедрения операторов SQL (SQL injection), возможность внедрения кода на языке Javascript (XSS) и т.п. Для обнаружения подобных недостатков подходят известные модели, основанные на потоках данных (например, модель non-interference, которая после была адаптирована в т.н. taint analysis), или классические задачи статического анализа (например, анализ возможных значений переменных).

К специфичным недостаткам принято относить все недостатки в реализации логики приложения. Другими словами, если для описания недостатка словами используются термины из предметной области приложения, то такой недостаток является специфичным.
Примерами таких недостатков являются в первую уязвимости контроля доступа, уязвимости, связанные с недостаточным контролем последовательности шагов в сценариях использования (Insufficient Process Validation), а также логические бомбы с другими НДВ.

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

С методической точки зрения задачу поиска специфичных уязвимостей на западе решают в научных кругах (по крайней мере, для веб-приложения) с 2008 года. Достаточно привести в пример такие работы, как «Toward automated detection of logic vulnerabilities in web applications», «Static detection of logic flaws in service-oriented applications», «Static detection of access control vulnerabilities in web applications» и др. С практической же точки зрения дела обстоят намного интереснее: многие автоматизированные средства (статические анализаторы) поиска недостатков безопасности в коде заявляют, что умеют находить в приложениях не только типичные недостатки, но и специфичные.

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

В продолжение анализа будет описана роль человека и ручного анализа в задачах а) дешевого поиска специфичных уязвимостей; б) максимально полного поиска специфичных уязвимостей. Здесь же будет представлена наша методика поиска подобных ошибок на примере поиска ошибок контроля доступа: задача будет декомпозирована на шаги, для каждого из которых будет указано, что можно сделать автоматически и как, а что — только вручную.

Реклама
  1. 22.03.2013 в 20:09

    А будут рассмотрены только свободное ПО или и проприетарное тоже?

  2. 24.03.2013 в 23:19

    oxdef :

    А будут рассмотрены только свободное ПО или и проприетарное тоже?

    Я бы все-таки хотел оставаться на методическом уровне. Т.е. я буду говорить, что такой-то класс интсрументов, например, реализует pattern-matching, входной алфавит — лексемы/элементы AST/…, а механизм matchning’а — регулярные выражения или автомат с памятью. Как-то так.

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: