📚 Пост AI-Powered Fuzzing: Breaking the Bug Hunting Barrier
В 2016 году Google запустила бесплатный сервис для фаззинга открытого ПО OSS-Fuzz. Это произошло после обнародования нескольких критических уязвимостей типа Heartbleed, которые, как обнаружилось, можно было предотвратить, если бы разработчики использовали фаззинг.
Чтобы использовать OSS-Fuzz, разработчик реализует фаззеры для своего проекта и конфигурирует взаимодействие с сервисом. Сервис запускает фаззеры, собирает результаты, приватно сообщает разработчикам о найденных багах, а затем следит за обновлениями чтобы удостовериться, что разработчики смогли исправить баг. Открытые проекты обслуживаются бесплатно, а для закрытого кода можно запустить сервис на своей машине.
В среднем, код проектов, использующих OSS-Fuzz, покрывается не более, чем на 30%, потому что писать фаззеры приходится вручную. Это и трудно, и долго, а разработчики не всегда могут выделить на эту задачу ресурсы. Чтобы помочь разработчикам увеличить покрытие кода фаззерами, в августе 2023 инженеры Google реализовали протокол интеграции OSS-Fuzz с LLM, дабы языковые модели генерировали фаззеры без участия человека.
OSS-Fuzz идентифицирует непокрытые части проекта и формирует запрос к LLM. Запрос включает информацию о непокрытой части проекта. Код фаззера может автоматически уточняться у языковой модели в случае ошибок компиляции или если сгенерированный фаззер не увеличил покрытие кода.
Примеры запросов к LLM и system prompts.
В описании репозитория проекта авторы приводят результаты одного из экспериментов:
- 1300+ бенчмарков из 300 проектов ПО.
- В 160 проектах LLM cумела сгенерировать корректные фаззеры и увеличить покрытие на 10-30%.
К сожалению, неясно, какую LLM использовали для этого эксперимента — заявлена поддержка Vertex AI code-bison и code-bison-32k, Gemini Pro и OpenAI GPT-3.5-turbo и GPT-4.
#llm #fuzzing
В 2016 году Google запустила бесплатный сервис для фаззинга открытого ПО OSS-Fuzz. Это произошло после обнародования нескольких критических уязвимостей типа Heartbleed, которые, как обнаружилось, можно было предотвратить, если бы разработчики использовали фаззинг.
Чтобы использовать OSS-Fuzz, разработчик реализует фаззеры для своего проекта и конфигурирует взаимодействие с сервисом. Сервис запускает фаззеры, собирает результаты, приватно сообщает разработчикам о найденных багах, а затем следит за обновлениями чтобы удостовериться, что разработчики смогли исправить баг. Открытые проекты обслуживаются бесплатно, а для закрытого кода можно запустить сервис на своей машине.
В среднем, код проектов, использующих OSS-Fuzz, покрывается не более, чем на 30%, потому что писать фаззеры приходится вручную. Это и трудно, и долго, а разработчики не всегда могут выделить на эту задачу ресурсы. Чтобы помочь разработчикам увеличить покрытие кода фаззерами, в августе 2023 инженеры Google реализовали протокол интеграции OSS-Fuzz с LLM, дабы языковые модели генерировали фаззеры без участия человека.
OSS-Fuzz идентифицирует непокрытые части проекта и формирует запрос к LLM. Запрос включает информацию о непокрытой части проекта. Код фаззера может автоматически уточняться у языковой модели в случае ошибок компиляции или если сгенерированный фаззер не увеличил покрытие кода.
Примеры запросов к LLM и system prompts.
В описании репозитория проекта авторы приводят результаты одного из экспериментов:
- 1300+ бенчмарков из 300 проектов ПО.
- В 160 проектах LLM cумела сгенерировать корректные фаззеры и увеличить покрытие на 10-30%.
К сожалению, неясно, какую LLM использовали для этого эксперимента — заявлена поддержка Vertex AI code-bison и code-bison-32k, Gemini Pro и OpenAI GPT-3.5-turbo и GPT-4.
#llm #fuzzing
Google Online Security Blog
AI-Powered Fuzzing: Breaking the Bug Hunting Barrier
Dongge Liu, Jonathan Metzman, Oliver Chang, Google Open Source Security Team Since 2016, OSS-Fuzz has been at the forefront of automated v...
👍12
📚 Отчёт Wentao Gao, Van-Thuan Pham, Dongge Liu, Oliver Chang, Toby Murray, and Benjamin I.P. Rubinstein. 2023. Beyond the Coverage Plateau: A Comprehensive Study of Fuzz Blockers (Registered Report). In Proceedings of the 2nd International Fuzzing Workshop (FUZZING ’23), July 17, 2023
Отчёт анализирует некоторые причины проблемы плато, с которой сталкивается Coverage-Guided Greybox Fuzzing (CGF).
CGF это тип фаззинга, который характерен двумя особенностями. Во-первых, фаззер использует общую информацию об архитектуре программы для подбора значимых входов, но не знает её детальной структуры. Во-вторых, фаззер в процессе работы старается максимизировать покрытие кода трассами выполнения.
При CGF фаззер выполняет следующие шаги в цикле, пока не будет достигнут лимит времени:
1. Выбирает вход из накапливаемого множества входов (seed corpus).
2. Мутирует вход, пытаясь достигнуть непокрытых участков кода.
3. Запускает программу на мутированном входе. Если покрытие увеличилось, добавляет вход в seed corpus; при неожиданном поведении программы, например, ошибке времени выполнения, описывает этот случай в отчёте.
Алгоритмы CGF различаются правилами мутации, начальным заполнением seed corpus и другими деталями.
Эксперименты показывают, что современные фаззеры достаточно быстро выходят на плато, при котором покрытие кода перестает расти, сколько бы дополнительного времени ни получил фаззер.
Чтобы понять причины эффекта плато, авторы изучили результаты фаззинга трех популярных библиотек: libPNG, iGraph, OpenSSL с помощью утилиты FuzzIntrospector для cервиса OSS-Fuzz.
(Пример отчёта)
Фаззинг библиотек требует написания программ-оберток (drivers), которые запускают библиотечные функции. Этим занимаются, как правило, сами разработчики библиотек. По мнению авторов, чрезмерно упрощенные обертки являются важной причиной эффекта плато.
Анализ авторов показал, что проблемные ситуации часто возникали независимо от входов: в libPNG все 12 экспериментов показали плато на любых входах, а в iGraph — 9 из 22. Покрытие переставало увеличиваться по следующим причинам:
1. Аргументы функций в обертке зафиксированы. Например, библиотека iGraph поддерживает работу как с ориентированными, так и с неориентированными графами, но существующие обертки вызывали некоторые функции с такими фиксированными аргументами, что под фаззинг попадали только ориентированные графы.
2. Функции вообще не вызываются оберткой:
2.1. Вызываются не все перегрузки.
2.2. Ошибки бы проявились если бы функция была вызвана больше одного раза (например, init-функции).
2.3. Пропущены вызовы, которые могли бы настроить библиотеку на разные конфигурации.
2.4. Пропущены вызовы, добавляющие функциональность (например, установка обработчиков событий).
3. Функции вызываются только в "правильном", ожидаемом порядке, а ошибки проявляются лишь если перемешать вызовы.
4. Наличие объективно недостижимого кода.
Некоторые проблемы в обертке iGraph проявлялись только на определенных входах, которых фаззеры не достигали.
Это были крайние случаи — например, когда размер входного графа превышал предполагаемый лимит.
Неожиданно, но в эксперименте не возникло проблем, связанных с использованием контрольных сумм и магических чисел, хотя это известные проблемы для фаззинга.
Анализ фаззинга OpenSSL, видимо, будет включен в следующую работу.
В качестве решений проблем с обертками авторы предлагают рассмотреть автоматическую генерацию оберток и structure-aware fuzzing, имеющий полную информацию о коде программы.
#fuzzing
Отчёт анализирует некоторые причины проблемы плато, с которой сталкивается Coverage-Guided Greybox Fuzzing (CGF).
CGF это тип фаззинга, который характерен двумя особенностями. Во-первых, фаззер использует общую информацию об архитектуре программы для подбора значимых входов, но не знает её детальной структуры. Во-вторых, фаззер в процессе работы старается максимизировать покрытие кода трассами выполнения.
При CGF фаззер выполняет следующие шаги в цикле, пока не будет достигнут лимит времени:
1. Выбирает вход из накапливаемого множества входов (seed corpus).
2. Мутирует вход, пытаясь достигнуть непокрытых участков кода.
3. Запускает программу на мутированном входе. Если покрытие увеличилось, добавляет вход в seed corpus; при неожиданном поведении программы, например, ошибке времени выполнения, описывает этот случай в отчёте.
Алгоритмы CGF различаются правилами мутации, начальным заполнением seed corpus и другими деталями.
Эксперименты показывают, что современные фаззеры достаточно быстро выходят на плато, при котором покрытие кода перестает расти, сколько бы дополнительного времени ни получил фаззер.
Чтобы понять причины эффекта плато, авторы изучили результаты фаззинга трех популярных библиотек: libPNG, iGraph, OpenSSL с помощью утилиты FuzzIntrospector для cервиса OSS-Fuzz.
(Пример отчёта)
Фаззинг библиотек требует написания программ-оберток (drivers), которые запускают библиотечные функции. Этим занимаются, как правило, сами разработчики библиотек. По мнению авторов, чрезмерно упрощенные обертки являются важной причиной эффекта плато.
Анализ авторов показал, что проблемные ситуации часто возникали независимо от входов: в libPNG все 12 экспериментов показали плато на любых входах, а в iGraph — 9 из 22. Покрытие переставало увеличиваться по следующим причинам:
1. Аргументы функций в обертке зафиксированы. Например, библиотека iGraph поддерживает работу как с ориентированными, так и с неориентированными графами, но существующие обертки вызывали некоторые функции с такими фиксированными аргументами, что под фаззинг попадали только ориентированные графы.
2. Функции вообще не вызываются оберткой:
2.1. Вызываются не все перегрузки.
2.2. Ошибки бы проявились если бы функция была вызвана больше одного раза (например, init-функции).
2.3. Пропущены вызовы, которые могли бы настроить библиотеку на разные конфигурации.
2.4. Пропущены вызовы, добавляющие функциональность (например, установка обработчиков событий).
3. Функции вызываются только в "правильном", ожидаемом порядке, а ошибки проявляются лишь если перемешать вызовы.
4. Наличие объективно недостижимого кода.
Некоторые проблемы в обертке iGraph проявлялись только на определенных входах, которых фаззеры не достигали.
Это были крайние случаи — например, когда размер входного графа превышал предполагаемый лимит.
Неожиданно, но в эксперименте не возникло проблем, связанных с использованием контрольных сумм и магических чисел, хотя это известные проблемы для фаззинга.
Анализ фаззинга OpenSSL, видимо, будет включен в следующую работу.
В качестве решений проблем с обертками авторы предлагают рассмотреть автоматическую генерацию оберток и structure-aware fuzzing, имеющий полную информацию о коде программы.
#fuzzing
ACM Conferences
Beyond the Coverage Plateau: A Comprehensive Study of Fuzz Blockers (Registered Report) | Proceedings of the 2nd International…
👍16