Быстрый security-oriented fuzzing c AFL. Часть 1 | OTUS
⚡ Открываем подписку на курсы!
Проходите параллельно 3 онлайн-курса в месяц по цене одного.
Подробнее

Курсы

Программирование
Flutter Mobile Developer Подготовка к сертификации Oracle Java Programmer (OCAJP)
-8%
Супер-интенсив «СУБД в высоконагруженных системах»
-18%
Алгоритмы и структуры данных
-12%
Web-разработчик на Python
-11%
Архитектура и шаблоны проектирования
-14%
Team Lead
-15%
iOS-разработчик. Базовый курс
-23%
Разработчик на Spring Framework Python Developer. Basic
-16%
C# ASP.NET Core разработчик
-18%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-6%
Android-разработчик. Базовый курс
-10%
C++ Developer. Professional Разработчик C# AWS для разработчиков Software Architect Unity Game Developer. Basic Разработчик голосовых ассистентов и чат-ботов Backend-разработка на Kotlin React.js Developer Разработчик Node.js Нереляционные базы данных Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Advanced Fullstack JavaScript developer
Инфраструктура
Супер-интенсив «СУБД в высоконагруженных системах»
-18%
PostgreSQL
-10%
IoT-разработчик
-12%
Administrator Linux. Professional
-11%
Базы данных
-19%
Administrator Linux.Basic
-18%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-6%
Сетевой инженер AWS для разработчиков Software Architect Reverse-Engineering. Professional CI/CD VOIP инженер Супер-практикум по работе с протоколом BGP Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Быстрый 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 комментариев
Для комментирования необходимо авторизоваться