Возможно в вашей ленте уже проскочила новость о 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://www.tgoop.com/tech_b0lt_Genona/3540 и https://www.tgoop.com/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

4-5 декабря прошла конференция ISP RAS Open, которую из года в год организует ИСП РАН. Я в основном был на секции, посвященной SDL, но в других залах тоже было интересно. Например в Синем зале было много докладов, по теме фаззинга и модел-чекинга:

Доклады секции «Технологии анализа, моделирования и трансформации программ» (Синий зал):

1-й день, видеозапись https://www.youtube.com/watch?v=_PMywI4MTL0 (таймкоды в описании видео)

- Разработка прототипа безопасного компилятора на основе Clang
- Программный комплекс для измерения производительности базовых блоков на современных ЦПУ
- Разработка инструмента автоматического обнаружения гонок при параллельной сборке с использованием утилиты Маке
- Автоматизированная генерация модульных тестов для Java-программ при помощи фаззинга
- Проверка программ на соответствие стандарту MISRA С с использованием инфраструктуры Clang
- Обнаружение возможной перезаписи переменных вследствие использования функций нелокальных переходов
- Статический анализ языка со: контролируемая сборка
- Повышение точности моделирования библиотечных функций в статическом анализаторе
- Статический анализ на основе обобщенного абстрактного синтаксического дерева
- Повышение масштабируемости межмодульного статического анализа помеченных данных

2-й день, видеозапись https://www.youtube.com/watch?v=oMpSgMFFiXc (таймкоды в описании видео)

- Метод надежной пространственной изоляции для ARINC 653 OCPB
- Извлечение опорных тестовых наборов из спецификаций криптопротоколов на предметно-ориентированном языке
- Эффективное дополнение авто-активной верификации программ дедуктивными доказательствами
- Инструмент для поиска гонок по данным RaceHunter
- Моделирование операционных, программных и и технических систем в проектах РФФИ 2016-2022
- Награждение победителей контеста Veha
- Результаты переработки уровней ролевого управления доступом и мандатного контроля целостности формальной модели управления доступом ОС Astra Linux
- К моделированию системы обработки прерываний Linux для SMP систем
- Автоматический поиск фазз-блокеров
- Метод мутации сложноструктурированных входных данных при фаззинг тестировании JavaScript интерпретаторов
- Предикат безопасности для ошибки целочисленного усечения
- Фаззинг полиморфных систем в структурах микросервисов
- Язык программирования для обучения технологиям компиляции и трансформации
- Исследование возможности идентификации веб-сайтов, посещаемых пользователем, на основе НТТР/2 трафика

Чаты и каналы Telegram по информационной безопасности 2024: https://zlonov.ru/telegram-security-list-2024/

Спасибо всем кто пришел и смотрел. Рассказал о применении «модного» генеративного ИИ для задач инженера ИБ и фаззинге в частности.

Недавно security-команда Google в своем блоге рассказала о развитии и планах на oss-fuzz-gen. Об этом фреймворке и подобным решениям рассказывал на Дефкон НН, слайды с которого как раз опубликованы выше.

Напомню как работал фреймворк на момент релиза в опенсорс:

1. LLM генерирует черновик фаззинг-теста для указанной функции, читай пишет тест
2. Попытка запустить фаззинг-тест и если есть ошибки компиляции, отправляем запрос в LLM на как исправить и повторяем пока фаззинг-тест не запустится
3. Первый пробный запуск для поиска проблем уже в рантайме
4. Скорректированный фаззинг-тест отправляем на длительное фаззинг-тестирование, в тот же ClusterFuzz

В идеальной схеме такого фреймворка еще должен быть 5й пункт — исправление найденных уязвимостей. По словам команды у них есть уже наработки по этому пункту, но пока не готовы поделиться, поэтому советую доклад от Романа «Исправлять — не искать. Разработка и внедрение AI-ассиcтента для исправления уязвимоcтей в коде» с прошедшего Highload 2024. Хотя за прошедшее время они улучшили 1-4 пункты, в частности в 4 добавился триаж и выглядит он интересн, назвал бы промежуточным шагом между 4 и 5:

LLM Response: Crash is caused by bug in fuzz driver.

The fuzz driver creates a vector of iovec structures, each pointing to a chunk of memory owned by the FuzzedDataProvider. However, the data_chunk vector, which holds the actual data pointed to by iov_base, is deallocated at the end of each fuzzer iteration when it goes out of scope. This leaves the iov_base pointers dangling. When snappy::CompressFromIOVec tries to access the memory pointed to by these dangling pointers, a heap-use-after-free occurs

Еще было интересно узнать текущие результаты использования 

- В 272 C/C++ проектах увеличилось покрытие фаззинг. В одном проекте покрытие увеличилось в 7000% раз
- 26 найденных уязвимостей
- Критическая уязвимость в OpenSSL - CVE-2024-9143

Уязвимость в OpenSSL выделяется тем, что это первая уязвимость найденная с помощью LLM, читай их фреймворка, в критическом ПО и которое «давно всеми проверяется и тестируется».

Ребята из Cyber Media "поймали" после очередного митапа и позадавали разные вопросы про фаззинг-тестирование: от что это вообще такое до как попробовать — https://www.tgoop.com/secmedia/2338 или ссылка сразу на интервью. Enjoy!

Думал подождать Нового года, но раз тут достигли красивой IT-цифры — первых 256 подписчиков (за что всем огромнейшее Спасибо!), то решил, что самое время. Да и есть те, кто нарядил ёлочку, украсил аватарки и логотипы проектов и прочее уже 1-го декабря.

Зайчик из AFL мне, конечно, импонирует, а уж сколько находок во время тестирования помог найти — и не счесть, но хотелось что-то своё. В общем, взял нафаззеную мешанину идей, а Аня из @onoividno воплотила в жизнь. Теперь у канала есть маскот Фазя со своим набором стикеров и emoji. Набросков ещё хватает, поэтому стикерсет будет пополняться, но идеи приветствуются. :)

P. S. Когда-нибудь расскажу историю появления этого персонажа, некоторые даже скажут — грустную... Вышло в некотором роде символично.