РИТ++ / 2010: презентация с выступления

Довелось сегодня выступать на мероприятии под названием "Российские интернет-технологии 2010" (сокр. РИТ++) по теме "Анализ защищенности интернет-проектов". Презентация с выступления представлена ниже.




И скромный фото-отчет с мероприятия доступен здесь.

11 комментариев :

  1. > в тему: Уязвимость в WordPress стала причиной взлома сотен блогов
    упс... )

    p.s. Кстати, если тебе интересен feed back по презентации, у меня есть что сказать по поводу статического und динамического анализа

    ОтветитьУдалить
  2. Не дает все запостить сразу, поэтому по частям...

    Дело в том, что статическим анализатором люди называют все, что анализирует исходный код (даже grep :))
    Если смотреть глубже, то есть несколько типов статического анализа:
    - сигнатурный
    - основанный на моделях уязвимостей
    - верификация
    Сигнатурный метод самый простой. Мы переводим программу в промежуточное представление (например, CFG) и ищем "плохие" конструкции. Так, например, работает RATS. Тут ты правильно написал фундаментальное ограничение.
    Однако большинство коммерческих статических анализаторов работают по-другому. Они тоже переводят программу во внутреннее представление (CFG + зависимости по данным). Отличия начинаются далее. Есть общепринятые модели уязвимостей в терминах этих самых внутренних представлений программы (например, в терминах зависимостей). Вот анализаторы берут и проверяют, удовлетворяет ли граф программы требованиям модели. Если да - нашли уязвимость, если нет - всё оке. Простейшая модель уязвимости - это наличие зависимости по данным аргументов критических операций (например, mysql_query) от пользовательского ввода (например, $_GET['arg']) без фильтрации (например, addslashes) - то есть банальный поиск пути в графе.
    Про верификацию не буду :)

    ОтветитьУдалить
  3. Теперь по поводу бонусов, которые дает статический анализ. Мы имеем исходный код, а значит видим все пути выполнения программы. А это значит, что он мы можем провести полный консервативный анализ: если он скажет, что уязвимостей нет, значит их нет на самом деле. (например, пометить все вызовы mysql_query уязвимыми, хыхы) Плата за это - большое число ложных срабатываний из-за фундаментальных ограничений статического анализа (см. Теорема Райса). Если на пальцах, то во время статического анализа мы должны делать предположения (например, сколько итераций будет в цикле, какова глубина рекурсии, каково содержимое контейнеров типа списков и хэш-таблиц), которые и влияют на точность анализа.

    В динамическом анализе используются те же модели уязвимостей, что и в статическом анализе (например, распространение метки taint - это всего лишь способ определения зависимостей по данным). Разница в том, что мы рассматриваем конкретный путь выполнения с конкретными входными данными. А значит, мы знаем все значения переменных в каждой точке программы. Отсюда точность анализа (нет false positive) и его неполнота - уязвимости могут проявляться на других путях выполнения при других исходных данных. А создание полного тестового покрытия - увы тоже неразрешимая задача :)

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

    p.s. ну по мелочи - ты перепутал ошибки первого и второго рода :) (http://ru.wikipedia.org/wiki/Ошибки_первого_и_второго_рода)

    ОтветитьУдалить
  5. спасибо за полезный и подробный комментарий! :)

    ОтветитьУдалить
  6. Владимир Тигров13 апреля 2010 г. в 23:18

    Именно поентому все продвинутые пацаны идут по пути комбинации статики с динамикой или на худой конец - fault injection. Чтобы стало-быть уточнять и вешать вероятности наличия уявзвимости и все такое.
    Кстати, не соглашусь с коллегой по поводу "нет false positive" в динамике. Классический пример - XSS. Где критерии "наличия уязвимости" очень меняются от браузера/версии. Ужесточишь критерии - и все - половину багов не видишь.

    ЗЫ. https://365.rsaconference.com/blogs/podcast-series-rsa-conference-2010/2010/02/03/and-302-best-of-both-worlds-correlating-static-and-dynamic-analysis-results

    ОтветитьУдалить
  7. В любом случае весь статический анализ упрётся в проблему останова, в общем случае :)

    ОтветитьУдалить
  8. > Кстати, не соглашусь с коллегой по поводу "нет false positive" в динамике.

    Good point. Я имел в виду, что нет false positive в терминах проверки свойств модели - ибо она построена точно. Ограничения модели (но это проблема модели) - да, дают ложные срабатывания. Например, если мы в tainted mode делаем фильтрацию через ветвление:
    input = get_HTTP_param(‘username’)
    if (input.contains(’badchars’)) {
    // return error page
    // if we untaint variable input, then we could get an XSS in the first branch
    } else {
    // do processing
    // if we do not untaint then we could get a false positive at the sink in the second branch
    }

    Эту проблему можно решить, добавив анализ строк, но это уже выход за пределы модели. Напомню, в модели у нас есть фильтрующие функции, которые возвращают "хорошие" данные во всех путях )

    ОтветитьУдалить
  9. Владимир Тигров14 апреля 2010 г. в 12:09

    > false positive в терминах проверки свойств модели - ибо она построена точно

    Люблю "научных" людей!

    ОтветитьУдалить