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

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

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

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()).

Эта функция обрабатывает входные данные некорректно. Если вы передадите в неё путь, состоящий из нуль-байта либо двойной кавычки, библиотека назначит нуль-байт по отрицательному указателю массива 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 видим результат анализа:

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

PVS Studio

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

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

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