Недавно 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, читай их фреймворка, в критическом ПО и которое «давно всеми проверяется и тестируется».
Напомню как работал фреймворк на момент релиза в опенсорс:
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, читай их фреймворка, в критическом ПО и которое «давно всеми проверяется и тестируется».