Первые дни весны нас порадовали не только резкой теплой погодой, но и новым релизом продвинутого форка - afl++ 3.10c. Из интересного:

- Улучшена поддержка Android и macOS (ARM64!)
- Для qemuafl портирован QASan (это Address Sanitizer для Qemu)
- Для unicornafl улучшены Python и Rust биндинги
- В afl-cc теперь можно использовать LLVMFuzzerTestOneInput

Ещё хотелось бы напомнить, что этот год начался для afl++ и так с хороших новостей, в базовых образах для фаззинга знаменитого комплекса oss-fuzz обычный afl был заменен как раз на afl++.

Помимо новой версии afl++ вышла и первая статья Fuzzing grub: part 1 из цикла о поиске баг методом фаззинга с помощью afl++ в популярной утилите grub. От других подобных статей, помимо полученных CVE (CVE-2021-20225 and CVE-2021-20233), ещё отличает то, что автор не просто запустил фаззинг в qemu-режиме, но разобрался в коде и показал подход через патчинг - когда после успешной загрузки входных данных мы искусственно завершаем работу программу без ошибок.

Тем кто захочет повторить за автором, советую пропустить ошибки, которые решил автор и сразу взять его форк https://github.com/daxtens/grub, выбрать ветку fuzzing-pt1 и скомпилировать программу с флагом make CFLAGS="-DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION"

А пока ждём следующие части, продолжаем фаззить.

1 Июля мейтейнер curl Daniel Stenberg написал в личном блоге о результатах использования фаззинга в течении 5 лет с помощью OSS-Fuzz. curl был добавлен в гугловскую фаззинг-ферму одним из первых и в последствии улучшен энтузиастом Max Dymond. Изначально это был одиночный фаззер и затем разросся до отдельного проекта для тестирования надежности curl.

Даниел приводит отличное описание фаззинга после его многолетнего использования - это некст-левел для проектов, когда компиляторы уже не показывают предупреждения (да, такое бывает), а статические анализаторы показывают 0. Так как найденные ошибки фаззингом часто пропускаются при статическом анализе и труднозаметны во время ревью кода.

Если изначально OSS-Fuzz направлен на непрерывный фаззинг, то в 2020 Google представили CIFuzz, цель которого на каждый PR (commit?) проводить фаззинг-тестирование ограниченное время. К примеру, в случае гитхаб это максимум 6 часов. Хотя я бы советовал не меньше 2-3 дня при технической возможности. Такой подход позволил разработчикам устранить много неприятных багов в мастер ветке проекта, а после нескольких лет использования количество уведомлений об ошибках становится меньше и меньше.

Для специалистов по ML есть платформа Kaggle, где они могут посоревноваться с другими командами в умении решать задачи с помощью ML и даже заработать денег. Для специалистов в области ИБ есть формат соревнований CTF (Capture the flag). Для специалистов в тестировании нет ни популярного формата таких соревнований ни какой-либо платформы. Расскажу о тех соревнованиях, про которые знаю. И то и друго находится на стыке ИБ и тестирования, но тем не менее.

Rode0day - каждый месяц публикуют набор исполняемых файлов с ошибками, за каждый найденный креш вы получаете баллы. В конце месяца анонсируется победитель с максимальным количеством баллов.

Марсель Беме (Marcel Böhme), известный (см. публикации) исследователь в области безопасности ПО, вместе с Google Open Source Security Team анонсировал другое соревнование, в котором надо написать фаззер с интерфейсом, как у libFuzzer, для программ на C/C++ и добиться максимального покрытия и количества найденных багов на примерах программ из бенчмарка FuzzBench. Подробное описание - https://github.com/mboehme/FuzzingCompetition/tree/mboehme-patch-1, регистрация - https://forms.gle/QZgUYysoBizeAKRu9 Учитывая исследовательские интересы Марселя ("One part of his group develops the probabilistic foundations of automatic software testing (i.e., finding bugs by generating executions) to elucidate fundamental limitations of existing techniques and to explore the assurances that software testing provides when no bugs are found.") его интерес к этому соревнованию понятен. Формат немного противоположный формату Rode0day, но от этого не менее интересный.

После выхода FreeBSD advisory о переполнении стэка в ping OpenBSD-разработчик Florian Obser решил проверить наличие ошибки в OpenBSD реализации, так как приложил много сил к её разработке, о чём и результатах проверки написал в своём блоге.

В ходе проверки выяснилось, что эта ошибка не актуальна для них, так как FreeBSD-разработчики переписали уязвимую функцию pr_pack() ещё в 2019 и в OpenBSD соответственно осталась старая реализация. Но проблема в pr_pack() возникла из-за некорректной обработки не доверенных сетевых данных, а следовательно вероятность ошибок такого рода в старом коде даже может быть выше. Как пишет автор, он давно хотел попробовать фаззинг-тестирование, а когда пересекается одно с другим... В этом случае по итогу нашёлся баг возрастом 24+ лет, отсчет с коммита уязвимого кода.

Инструментарий:

- afl++;
- Запатченная версия ping, чтобы данные брались с диска, это частая практика, особенно при фаззинге с помощью afl.

Интересное:

- Лишний раз напоминание, что и зависания могут быть настоящими ошибками;
- У автора заняло 30 минут от прочтения статьи из туториалов afl++ до найденной ошибки в реальной программе.

Сегодня все в том или ином виде подводят итоги. Для этого канала главный итог, что я через ~3 года его начал наконец-то вести и теперь тем, что раньше писал для себя, команды и друзей-знакомых, делюсь здесь. Поэтому в новом году желаю всем не откладывать решения и чтобы всё у вас и всё ваше было надёжным! С Новым Годом!

P.S. Лого AFL++ по-моему отлично подходит для следующего года

Новый год начался с новой версии AFL++ 4.05c. Из интересного:

- К сожалению на новых версиях macOS часть функционала: libdislocator, libtokencap и т.п. пока что не работают, для желающих помочь с разработкой или следить за новостями создана эта issue
- добавлена фича afl_custom_fuzz_send, данные в таргет теперь можно отправлять напрямую аля IPC
- обновлен режим unicorn_mode
- обновлены мутаторы для Rust и LibAFL
- ...

В блоге Trail of Bits вышла статья "Keeping the wolves out of wolfSSL". Так как у меня был уже на ближайшее время запланирован пост о фаззерах сетевых протоколов, то думал закинуть статью в список на чтение "Someday", но что-то повелело мне прочитать её...

По сути в статье рассказывается о новом фаззере tlspuffin на модном Rust. Но он оказался специализированным и его цели это криптографические протоколы. tlspuffin базируется на модели угроз Долева-Яо и разработан по правилам LibAFL (на скриншоте структура tlspuffin). Да, для проверки подобных протоколов существуют ProVerif и Tamarin, но подобный фаззер позволяет найти логические баги при сложно уловимых состояниях

Для первоначального теста инструмент перенашёл, найденные Trail of Bits ранее, уязвимости CVE-2022-25640 and CVE-2022-25638 в wolfSSL, а затем смог найти новые (процесс фаззинга в среднем занял около часа на каждую из них):

- DOSC (Denial of service against clients): CVE-2022-38153
- DOSS (Denial of service against servers): CVE-2022-38152
- BUF: CVE-2022-39173
- HEAP: CVE-2022-42905

Как пишет автор, в случае первой уязвимости для воспроизведения баги потребовалось бы организация около 30 разных соединений. Но этого не потребовалось, так как tlspuffin позволяет воссоздать необходимое состояние и затем проанализировать в GDB. Причиной баги оказалось наличие некоего глобального общего состояния между клиентами, что немного удивительно для такой библиотеки.

Интерфейс tlspuffin позволяет добавить проверки и для других протоколов, хотя это может потребовать значительное количество времени. К примеру, у команды ушло 5-6 недель на добавление SSH, но добавив один раз это можно будет переиспользовать. Так tlspuffin можно использовать для создания тестовых наборов, а с помощью полученных результатов проводить регрессионные тесты. То есть по сути может заменить TLS-Attacker

Как правильно заметили авторы в заключении, TLS протоколы, это та повседневная и повсеместная вещь, которой мы "доверяем" и поэтому её безопасность действительно важная вещь