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

Курсы

Программирование
Разработчик на Spring Framework
-5%
iOS Developer. Professional
-8%
Golang Developer. Professional
-6%
Базы данных
-12%
Agile Project Manager
-5%
C# ASP.NET Core разработчик
-6%
Android Developer. Basic
-10%
React.js Developer
-4%
MS SQL Server Developer
-8%
Scala-разработчик
-8%
Java Developer. Basic
-8%
Алгоритмы и структуры данных
-9%
Разработчик IoT
-13%
PostgreSQL
-8%
Подготовка к сертификации Oracle Java Programmer (OCAJP) Python Developer. Professional Разработчик программных роботов (RPA) на базе UiPath и PIX Unity Game Developer. Basic Разработчик голосовых ассистентов и чат-ботов Node.js Developer Интенсив «Оптимизация в Java» Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes iOS Developer. Basic Супер-интенсив «СУБД в высоконагруженных системах» Супер-интенсив "Tarantool"
Инфраструктура
DevOps практики и инструменты
-12%
Базы данных
-12%
Network engineer. Basic
-10%
Network engineer
-4%
Инфраструктурная платформа на основе Kubernetes
-6%
Экспресс-курс по управлению миграциями (DBVC)
-10%
Мониторинг и логирование: Zabbix, Prometheus, ELK
-10%
Administrator Linux. Professional
-6%
Разработчик IoT
-13%
Основы Windows Server Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов VOIP инженер Супер-практикум по работе с протоколом BGP NoSQL Супер-практикум по использованию и настройке GIT Супер-интенсив «СУБД в высоконагруженных системах» Экспресс-курс «IaC Ansible»
Специализации Курсы в разработке Подготовительные курсы
+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 комментариев
Для комментирования необходимо авторизоваться