nccgroup/triforceaflФаззинг AFL/QEMU с полно-системной эмуляцией.
Новое: для тех, кто хочет поиграться с TriforceAFL и TLSF, Richard Johnson создал Dockerfile, который устанавливает оба компонента (и даже собирает ядро Linux за вас). Он доступен здесь https://hub.docker.com/r/moflow/afl-triforce/tags/.
Ещё новое: afl-tmin теперь работает с fork-сервером!
https://github.com/nccgroup/TriforceAFL Jesse Hertz [email protected] Tim Newsham [email protected]
Это модифицированная версия AFL с поддержкой полносистемного фаззинга с использованием QEMU. Включённый QEMU обновлён, чтобы обеспечить трассировку ветвлений при запуске системного эмулятора для x86_64. Добавлены дополнительные инструкции для запуска fork-сервера AFL, задания параметров фаззинга и отметки начала и конца тестовых примеров.
Примечание: не все инструменты AFL были протестированы с новыми изменениями. Некоторое тестирование прошли следующие инструменты:
Для сборки:
make
Чтобы получить карту покрытия:
echo hello > /tmp/hello
./afl-showmap -o coverage.txt -QQ --
./afl-qemu-system-trace -kernel ../bzImage
-initrd ../initramfs.cpio.gz -m 1G -nographic
-append "console=ttyS0" -aflFile /tmp/hello
cat coverage.txt
Чтобы запустить фаззинг:
egrep ' (panic|log_store)$' ../mykern/kallsyms ffffffff8108e570 t log_store ffffffff8181064b T panic
mkdir inputs
echo hello > inputs/hello
./afl-fuzz -i inputs -o outputs -QQ --
afl-qemu-system-trace -kernel bzImage -initrd root.cpio.gz
-m 1G -nographic -append "console=ttyS0"
-aflPanicAddr ffffffff8181064b -aflDmesgAddr ffffffff8108e570
-aflFile @@
(Примечание: в отличие от использования опции "-Q", при использовании опции "-QQ" необходимо указывать полную командную строку для afl-qemu-system-trace).
Более подробную информацию об использовании этой модифицированной версии AFL см. в нашем фаззере системных вызовов Linux: https://github.com/nccgroup/TriforceLinuxSyscallFuzzer.
Новые флаги AFL: -QQ - использовать qemu в режиме полносистемной эмуляции вместо пользовательского режима (-Q)
Новые флаги QEMU: -aflFile - Имя файла, содержащего входные данные фаззера -aflPanicAddr - Адрес функции kernel panic для обнаружения паники -aflDmesgAddr - Адрес в ядре Linux функции журналирования dmesg для обнаружения журналирования и перехвата сообщений журнала
Новые инструкции QEMU: 0f 24 - aflCall edi=1 startForkserver(esi=enableTicks) Запускает fork-сервер AFL. После этой точки каждый тест будет выполняться в отдельном дочернем процессе, созданном через fork. Если enableTicks отличен от нуля, QEMU повторно включит таймер ЦП после создания дочернего процесса, в противном случае он не будет включён. edi=2 getWork(esi=ptr, edx=sz) Заполняет ptr[0..sz] следующим входным тестовым примером. Возвращает фактический заполненный размер (<= sz). edi=3 startWork(esi=ptr) Сообщает AFL о начале трассировки. Аргумент указывает на буфер с двумя квадрословами, задающими начальный и конечный адреса трассируемого кода. Инструкции вне этого диапазона не трассируются. edi=4 doneWork(esi=exitCode) Сообщает AFL, что тестовый пример завершён. Если обнаружена паника, AFL немедленно остановит тестовый пример. В противном случае он будет выполняться до вызова doneWork. Указанный exitCode возвращается в AFL. (Код может, но в настоящее время не делает этого, выполнять OR со значением 64 для всех кодов возврата, если во время тестового примера были обнаружены какие-либо журналы dmesg.)
Новый блочный драйвер QEMU: -drive filename=privmem: Этот блочный драйвер хранит образ диска в памяти с копированием при записи (copy-on-write), поэтому изменения никогда не сохраняются на диск. Изменения, внесённые одним тестовым примером, изолированы от других тестовых примеров.
Автор и сопровождение: Michal Zalewski [email protected]
Copyright 2013, 2014, 2015, 2016 Google Inc. Все права защищены. Выпущено на условиях Apache License, Version 2.0.
Новые версии и дополнительную информацию смотрите на: http://lcamtuf.coredump.cx/afl/
Чтобы обменяться опытом с другими пользователями или получать уведомления о крупных новых возможностях, отправьте письмо на [email protected].
** Если у вас нет времени читать этот файл, обратитесь к QuickStartGuide.txt. **
Фаззинг — одна из самых мощных и проверенных стратегий выявления проблем безопасности в реальном программном обеспечении; именно с ним связано подавляющее большинство обнаруженных на сегодняшний день ошибок удалённого выполнения кода и повышения привилегий в критически важном для безопасности ПО.
К сожалению, фаззинг также относительно поверхностен: слепые случайные мутации делают крайне маловероятным достижение некоторых путей выполнения в тестируемом коде, оставляя ряд уязвимостей совершенно недосягаемыми для этой техники.
Было предпринято множество попыток решить эту проблему. Один из ранних подходов, пионером которого стал Tavis Ormandy, — дистилляция корпуса (corpus distillation). Метод опирается на сигналы покрытия, чтобы выбрать подмножество интересных затравочных файлов из массивного высококачественного корпуса файлов-кандидатов, а затем фаззить их традиционными средствами. Подход работает исключительно хорошо, но требует наличия такого корпуса под рукой. Кроме того, измерения покрытия блоков дают лишь очень упрощённое понимание состояния программы и менее полезны для направления фаззинговых усилий в долгосрочной перспективе.
Другие, более сложные исследования были сосредоточены на таких техниках, как анализ потока программы («конколическое исполнение»), символьное исполнение или статический анализ. Все эти методы чрезвычайно многообещающи в экспериментальных условиях, но на практике страдают от проблем с надёжностью и производительностью — и в настоящее время не предлагают жизнеспособной альтернативы «слепым» техникам фаззинга.
American Fuzzy Lop — это фаззер переборного типа (brute-force), сочетающийся с чрезвычайно простым, но исключительно надёжным генетическим алгоритмом, направляемым инструментированием. Он использует модифицированную форму покрытия рёбер (edge coverage), чтобы без усилий улавливать тонкие локальные изменения потока управления программы.
Если немного упростить, общий алгоритм можно свести к следующему:
Загрузить предоставленные пользователем начальные тестовые примеры в очередь,
Взять следующий входной файл из очереди,
Попытаться сократить тестовый пример до минимального размера, не изменяющего измеряемое поведение программы,
Неоднократно мутировать файл, используя сбалансированный и хорошо изученный набор традиционных стратегий фаззинга,
Если какая-либо из полученных мутаций привела к новому переходу состояния, зафиксированному инструментированием, добавить мутированный результат как новую запись в очередь.
Перейти к пункту 2.
