Быстрый security-oriented fuzzing c AFL. Часть 1 | OTUS

Курсы

Курсы в разработке Подготовительные курсы
Работа в компаниях Компаниям Блог +7 499 110-61-65

Быстрый security-oriented fuzzing c AFL. Часть 1

Revers_Deep_26.8-5020-933535.png

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

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

American Fuzzy Lop (AFL)

В последнее время широкую популярность приобрёл фаззер от Michal Zalewski — American Fuzzy Lop (AFL). Это связано с его эффективностью, а также тем, что он отличается инструментацией кода на этапе компиляции, производительностью и ориентированностью на практическое применение. В American Fuzzy Lop не используются SMT solver'ы, поэтому AFL должен быть менее требовательным к ресурсам, следовательно, работать быстрее.

Давайте посмотрим, как можно использовать этот инструмент и проведём эксперимент, сравнив результаты работы AFL с результатами ряда инструментов для статического анализа.

Итак, для начала надо понять, работает ли фаззер на практике, а также определиться с тем, что будем фаззить. Для проверки возьмём заведомо уязвимую версию библиотеки libcurl — 7.34.0. Эта версия имеет уязвимость, описанную в CVE-2015-3145 (речь идёт об уязвимости в функции sanitize_cookie_path()).

1-20219-dae1e7.png

Эта функция обрабатывает входные данные некорректно. Если вы передадите в неё путь, состоящий из нуль-байта либо двойной кавычки, библиотека назначит нуль-байт по отрицательному указателю массива new_path, следовательно, испортит память на куче.

В первую очередь давайте проверим, каким образом на данную уязвимость реагируют статические инструменты анализа: PVS Studio, Coverity, Clang Static Analyzer.

Clang Static Analyzer

В Clang делаем так:

$ cd curl
$ mkdir build-clang
$ cd build-clang
$ cmake -DCMAKE_C_COMPILER=/path/to/clang/ccc-analyzer -DCMAKE_CXX_COMPILER=/path/to/clang/ccc-analyzer -DCMAKE_BUILD_TYPE=release ../
$ scan-build -o html make

Далее в директории html видим результат анализа:

2-20219-b1f253.png

Coverity

Теперь Coverity. Он перехватывает вызовы компилятора и запускался со следующими параметрами:

$ cov-analyze --dir cov --all --security --enable-constraint-fpp --enable-single-virtual --enable-fnptr --enable-callgraph-metrics -j 2 --inherit-taint-from-unions --override-worker-limit

3-20219-eb27a0.png

PVS Studio

Что касается PVS Studio, то тут требуется Windows. Однако в trial-версии имена проблемных файлов не показываются, но мы ведь уже знаем строку и тип ошибки, а значит, для бинарной оценки этого будет вполне достаточно. PVS Studio запускался в режиме монитора, причём для простоты сборки задействовался скрипт build-libcurl-windows. Ниже мы приводим не весь вывод PVS Studio:

4-20219-f198f5.png

Результат нашей работы следующий: никакой из статических анализаторов проблему не обнаружил!

Что же, давайте теперь попробуем запустить процесс фаззинга. Но мы сделаем это в следующей части нашей статьи и подробно узнаем, как надо использовать American Fuzzy Lop для тестирования приложений. Следите за обновлениями блога!

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться