Первые дни весны нас порадовали не только резкой теплой погодой, но и новым релизом продвинутого форка - 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 протоколы, это та повседневная и повсеместная вещь, которой мы "доверяем" и поэтому её безопасность действительно важная вещь

Возможно в вашей ленте уже проскочила новость о RCE в git (Привет @xakep_ru!), эти и другие уязвимости со слабостями нашла команда X41 D-SEC в рамках аудита безопасности кода git по заказу GitLab. По результатам команда опубликовала подробный отчёт, который рекомендую для ознакомления всем интересующимся. Хоть и основной упор этого исследования делался на статическом аудите кода, но фаззинг-тестирование с помощью libFuzzer и AFL++ в некоторой мере было всё равно проведено. Судя по отчёту, исследовалась 2.38.1 версия git.

По итогу одна из проблем (по мнению исследователей не уязвимость, а слабость) - OOB (out-of-bound), обращение за границы массива, была найдена с помощью фаззинга (AFL++). Она находится в парсере MIDX формата и судя по тому, что последние изменения в этом файле были 28 Октября 2022, а отчёт в git-security отправили 9 Декабря 2022, то слабость до сих пор присутствует.

X41 рекомендует продолжить фаззинг-тестирование этого и других парсеров, а в приложении опубликованы как исходники фаззинг-тестов, так и необходимые патчи, которые позволили фаззить исследуемые компоненты программы. Сможете ли вы найти баги с помощью этих или модифицированных новые CVE? По опыту скажу, что это реально. Enjoy!

На большинстве ресурсов обсуждают сегодняшнюю новость, а в комментариях просят встать на раздачу https://t.iss.one/tech_b0lt_Genona/3540 и https://t.iss.one/ciso_on_fire/8. Но так как канал всё таки про фаззинг, поэтому думаю вам интересен архив fuzzing, внутри только json-конфиги с инфой по корпусам.

updated: @irez1a в комментариях поправил, что в остальных архивах можно найти сами фаззинг-тесты

20 Января 2023 в митап-баре @failoverbar прошла первая встреча в этом году сообщества безопасной разработки @sdl_community. Видеозапись была опубликована перед выходными и всем тем, кто по тем или иным причинам не смог посетить, Enjoy!

Среди различных докладов о безопасной разработке есть небольшой доклад по теме канала - "О фаззинге в PostgresPRO" от Николая Шаплова, где он поделился не только проблемами с которыми могут столкнуться те, кто будет имплементировать фаззинг в схожее монстроузное (с хорошей точки зрения!) ПО, но и как их решили или планируют решить. Ранее Николай на конференции Heisenbug 2021 представлял уже доклад "Как работает fuzzing-тестирование. Рассказ простым языком", где рассказал о своём фреймворке для struct-aware фаззинга libblobstamper, упомянутом и в этом докладе.

Вчера security-команда Google опубликовала результаты и планы для OSS-Fuzz в 2023 году:

- Во-первых, можно обновить цифры в личных презентациях 😏 - OSS-Fuzz нашёл 28000 ошибок, из них 8800 уязвимостей, в 280 проектах с открытым исходным кодом.
- Во-вторых, расширили программу вознаграждений OSS-Fuzz. Если кто не знал, вкратце, можно было написать фаззинг-тест и отправить в инфру OSS-Fuzz, в случае нахождения уязвимостей Google выплачивал награду. Теперь сюда входит:
* начальная интеграция или улучшение до "идеальной" интеграции с OSS-Fuzz
* увеличение покрытия у существующих фаззеров
* интеграция с FuzzBench и FuzzIntrospector
* интеграция нового санитайзера. Пример
* найденные уязвимости

- В-третьих, анонсировали поддержку JavaScript с помощью Jazzer.js (по нашему опыту у него лучше показатели, чем у jsfuzz) и представили новый фреймворк FuzzTest. На данный момент поддерживается только C++, но выглядит интересно. Как пишет Google - это новый стиль написания фаззинг-тестов взамен “старым” Fuzz Target
- В-четвертых, добавили поддержку FuzzIntrospector. Инструмент, который неплохо помогает в улучшении существующих фаззинг-тестов

В начале этого года закончился прием заявок на соревнование по написанию фаззеров - SBFT 2023. Спонсором была Google Open Source Security Team (GOSST), поэтому и одно из условий было, чтобы написанные фаззеры были интегрированы в FuzzBench. В качестве фаззеров можно было написать свой или модифицировать существующий, а результаты оценивались по количество найденных ошибок и достигнутому покрытию за 23 часа.

Результаты и релиз инструментов представили вчера в рамках SBFT мастер-класса на конференции ICSE 2023. Участвовало восемь команд, а победителями в двух номинациях стали решения: HasteFuzz, PASTIS и AFLrustrust.

Номинация: "Покрытие кода"
Победитель: HasteFuzz - модификация для AFL++, которая отфильтровывает потенциально дублирующиеся входные данные для повышения эффективности, что позволило покрыть большую поверхность кода за 23 часа
Приз: $11,337

Номинация: "Обнаружение ошибок"
Победитель: Разделили два решения PASTIS и AFLrustrust. Оба решения нашли 8 ошибок из возможных 15 против 7 у популярных решений:
* PASTIS - использует одновременно несколько фаззинг-движков: AFL++, hongfuzz и TritonDSE, которые независимо друг от друга тестируют разные участки кода
* AFLrustrust - модифицирует AFL++ в основе LibAFL таким образом, что отбрасывает лишние тестовые кейсы, тем самым повышая эффективность тестирования
Приз: поделили $11,337

Улучшения для AFL+++ и AFLSmart++ показали тоже достойные результаты и надеюсь они вольются в основную ветку.


Ребята из Google так же просят поучаствовать в развитии FuzzBench, заполнив опросник.

После такого подробного разбора от Сергея, даже добавить нечего. Кроме того, что это не первые попытки фаззинга CPU и после таких результатов они будут продолжаться

Tavis Ormandy, исследователь из Google Project Zero, сегодня в своем блоге раскрыл новую уязвимость в процессорах AMD Zen 2. Уязвимость Zenbleed затрагивает весь стек продуктов Zen 2, от процессоров AMD EPYC для центров обработки данных до процессоров Ryzen 3000, и может использоваться для кражи конфиденциальных данных, хранящихся в процессоре, включая ключи шифрования и учетные данные для входа. Атака может быть осуществлена даже удаленно через JavaScript на веб-сайте, а это означает, что злоумышленнику не нужно иметь физический доступ к компьютеру или серверу. Если у вас процессор AMD, то обязательно обновите микрокод в процессоре.

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

Производители регулярно используют фаззинг для тестирования своих процессоров, для такого тестирования есть даже отдельный термин — Post-Silicon Validation. Успех этой уязвимости был обусловлен использованием нетипичного источника обратной связи для фаззера и нетипичным тестовым оракулом.

Современные фаззеры используют источник обратной связи, чтобы генерировать данные, которые будут увеличивать покрытие. Проблема в том, что ничего похожего на покрытие кода в процессорах нет. Вместо счётчиков о покрытии использовали счетчики производительности, которые изначально предназначались для профилирования производительности программ. Некоторые из этих счетчиков срабатывают когда происходят всевозможные интересные архитектурные события. Это позволило находить интересные последовательности инструкций CPU.

Самый простой тестовый оракул в генеративном тестировании это "упадет"/"не упадет": передавать в программу сгенерированные данные и проверять, что нет необработанных исключений, нет аварийных завершений программы и т.д. При нормальном поведении программа не должна давать сбоев, этот постулат и используется в тестовом оракуле. С использованием такого тестового оракула для тестирования ПО всё понятно, но как узнать, что CPU правильно выполняет случайно сгенерированную программу? Один из подходов называется реверси. Общая идея состоит в том, что для каждой случайной инструкции, которую вы генерируете, вы также генерируете обратную ей (например, ADD r1, r2 → SUB r1, r2). Любое отклонение от начального состояния в конце выполнения должно быть ошибкой. Реверсивный подход хорош, но он усложняет создание тестовых сценариев для архитектуры CISC, такой как x86.

В случае с Zenbleed использовался другой тестовый оракул, который назвали "сериализованный оракул". Во время фаззинга отслеживается макроархитектурное состояние, как например значения регистров. Существует также микроархитектурное состояние, которое в основном невидимо для нас, например, предсказатель ветвлений, состояние спекулятивного выполнения инструкций и конвейер инструкций. Сериализация позволяет иметь некоторый контроль над этим, указывая CPU отключить параллельное выполнение инструкций. Основная идея сериализованного оракуласостоит в том, чтобы сгенерировать случайную программу, а затем автоматически преобразовывать её в сериализованную форму. Случайно сгенерированная последовательность инструкций и та же последовательность, но с добавлением рандомизированного выравнивания (см. пример инструкций), сериализации и спекулятивных ограждений. Эти две программы могут иметь разные характеристики производительности, но они должны выдавать одинаковый результат. Если конечные состояния не совпадают, то, должно быть, была какая-то ошибка в том, как они были выполнены на уровне микроархитектуры, что может указывать на ошибку. Так Zenbleed и обнаружили - вывод сериализованного оракула не совпал.

via

Вот и прошёл Offzone 2023, все гости вернулись по своим городам и странам. Спасибо организаторам, что позволили представить наш большой опенсорс проект. Отдельно хотелось бы отметить по тематике канала, что первая половина основного трэка второго дня у организаторов получилась некой лайт-версией европейской конференции Fuzzcon. Так и до отдельной конференции, посвященной фаззингу, недалеко :) Доклады получились и про инструменты и про процессы, так что ждём в записи:

- Как пофаззить тысячи приложений: практическое руководство
- Разнообразие фаззинг-ферм, и зачем делать свою
- CASR: ваш спасательный жилет в море крешей
- Фаззинг для SDL: выбрать, накрыть, раскопать

А мы, как и обещали, опубликовали исходники своей фаззинг фермы и нашего blackbox api-фаззера - shelob. Сейчас открыта локальная - версия под "маленький" кубер - Kind. А позже будет опубликованы версии, точнее скорее настройки, под различные облачные сервисы, что мы и сами использовали.

Вот и записи докладов подъехали. К сожалению видео пока есть не у всех, но услышать про разные решения и узнать больше про «пет-проект» BondiFuzz можете уже сейчас https://youtu.be/rpbiQzz53Tk