strongcourage/uafuzzUAFuzz: Двоично-ориентированный направленный фаззинг для уязвимостей типа "использование после освобождения"
Directed Greybox Fuzzing (DGF) такой как AFLGo нацелен на стресс-тестирование заранее выбранных потенциально уязвимых целевых мест, с приложениями к различным контекстам безопасности: (1) воспроизведение ошибок, (2) тестирование патчей или (3) верификация отчетов статического анализа. В последнее время появилось больше исследовательских работ, улучшивших эффективность и производительность направленного фаззинга (см. awesome-directed-fuzzing).
Мы предлагаем UAFuzz — направленный фаззер, специализированный на уязвимостях типа Use-After-Free (UAF) на уровне бинарного кода, путем тщательной настройки ключевых компонентов направленного фаззинга для учета специфических характеристик этого класса ошибок. Ошибки UAF возникают, когда элемент кучи используется после того, как был освобожден. Обнаружение UAF-ошибок сложно: (1) сложность, поскольку входные данные Proof-of-Concept (PoC) должны инициировать последовательность из трех событий – alloc, free и use – в одной и той же области памяти, охватывая множество функций тестируемой программы, и (2) тишина, без segmentation fault.
В целом, UAFuzz имеет рабочий процесс, аналогичный направленным фаззерам, с нашими модификациями, выделенными оранжевым цветом на протяжении всего процесса фаззинга, как показано на следующем рисунке. Поскольку мы сосредоточены на (1) воспроизведении ошибок и (2) тестировании патчей, мы с большой вероятностью имеем (в основном) полные стек-трейсы всех связанных с памятью событий UAF. В отличие от существующих общих направленных подходов, где цели могут выбираться независимо, мы учитываем взаимосвязь между целями (например, порядок, который важен для UAF), чтобы улучшить направленность. Во-первых, статическое предварительное вычисление UAFuzz является быстрым на уровне бинарного кода. Во-вторых, мы вводим новые метрики входных данных, учитывающие порядок, чтобы направлять фаззер к целям во время выполнения. Наконец, мы триажируем только потенциальные входные данные, охватывающие все цели в ожидаемом трейсе, и предварительно отфильтровываем входные данные для free, которые с меньшей вероятностью вызовут ошибку.
Больше подробностей в нашей статье на RAID'20 и в нашем докладе на Black Hat USA'20. Также благодарим Sébastien Bardin, Matthieu Lemerre, проф. Roland Groz и особенно Richard Bonichon (@rbonichon) за его помощь с Ocaml.
Наша тестовая среда: Ubuntu 16.04 64-bit.
# Install Ocaml and prerequisite packages for BINSEC via OPAM
sudo apt update
sudo apt update
sudo apt install ocaml ocaml-native-compilers camlp4-extra opam emacs llvm-6.0-dev pkg-config protobuf-compiler libgmp-dev libzmq3-dev cmake valgrind
opam init
opam switch 4.05.0
opam depext conf-m4.1
opam install merlin ocp-indent caml-mode tuareg menhir ocamlgraph ocamlfind piqi zmq.5.0.0 zarith llvm.6.0.0
eval `opam config env`
# Install Python's packages (Python 2 for IDA's scripts)
sudo python -m pip install networkx pydot
sudo apt install graphviz
# Install Graph Easy
wget https://cpan.metacpan.org/authors/id/S/SH/SHLOMIF/Graph-Easy-0.76.tar.gz
tar xzf Graph-Easy-0.76.tar.gz
cd Graph-Easy-0.76
perl Makefile.PL; make test; sudo make install
export GRAPH_EASY_PATH=/usr/local/bin/graph-easy
# Checkout source code
git clone https://github.com/strongcourage/uafuzz.git
# Environment variables
export IDA_PATH = /path/to/ida-6.9/idaq
export GRAPH_EASY_PATH=/path/to/graph-easy
cd uafuzz; export UAFUZZ_PATH=`pwd`
# Compile source code
./scripts/build.sh uafuzz
# Help for IDA/UAFuzz interface
./binsec/src/binsec -ida-help
./binsec/src/binsec -uafuzz-help
Наш фаззер построен на основе AFL v2.52b в режиме QEMU для фаззинга и BINSEC для легковесного статического анализа (см. uafuzz/README.md). В настоящее время мы используем IDA Pro v6.9 для извлечения графов потоков управления (CFG) и графа вызовов тестируемого бинарного файла (см. ida/README.md).
uafuzz
├── binsec/src
│ └── ida: a plugin to import and process IDA's CFGs and call graph
│ └── uafuzz: fuzzing code
│ │ └── afl-2.52b: core fuzzing built on top of AFL-QEMU
│ │ └── uafuzz_*.ml(i): a plugin to compute static information and communicate with AFL-QEMU
└── scripts: some scripts for building and bug triaging
Сначала рассмотрим простую UAF-ошибку. Ни AFL-QEMU, ни даже направленный фаззер AFLGo с целями на уровне исходного кода не могут обнаружить эту ошибку в течение 6 часов, в то время как UAFuzz может обнаружить её за несколько минут с помощью отчета Valgrind об UAF.
# Run AFL-QEMU
$UAFUZZ_PATH/tests/example.sh aflqemu 360
# Run AFLGo given targets at source-level
$UAFUZZ_PATH/tests/example.sh aflgo 360
# Run UAFuzz
$UAFUZZ_PATH/tests/example.sh uafuzz 360 $UAFUZZ_PATH/tests/example/example.valgrind
Для реальных программ мы используем UAF Fuzzing Benchmark для наших оценок.
# Checkout the benchmark
git clone https://github.com/strongcourage/uafbench.git
cd uafbench; export UAFBENCH_PATH=`pwd`
Мы подробно покажем, как запустить UAFuzz для воспроизведения ошибки CVE-2018-20623 в readelf (Binutils). Трассы стека этой UAF-ошибки, полученные с помощью Valgrind, следующие:
// stack trace for the bad Use
==5358== Invalid read of size 1
==5358== at 0x40A9393: vfprintf (vfprintf.c:1632)
==5358== by 0x40A9680: buffered_vfprintf (vfprintf.c:2320)
==5358== by 0x40A72E0: vfprintf (vfprintf.c:1293)
[6] ==5358== by 0x80AB881: error (elfcomm.c:43)
[5] ==5358== by 0x8086217: process_archive (readelf.c:19409)
[1] ==5358== by 0x80868EA: process_file (readelf.c:19588)
[0] ==5358== by 0x8086B01: main (readelf.c:19664)
// stack trace for the Free
==5358== Address 0x4221dc0 is 0 bytes inside a block of size 80 free'd
==5358== at 0x402D358: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
[4] ==5358== by 0x8086647: process_archive (readelf.c:19524)
[1] ==5358== by 0x80868EA: process_file (readelf.c:19588)
[0] ==5358== by 0x8086B01: main (readelf.c:19664)
// stack trace for the Alloc
==5358== Block was alloc'd at
==5358== at 0x402C17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
[3] ==5358== by 0x80AD97E: make_qualified_name (elfcomm.c:906)
[2] ==5358== by 0x8086350: process_archive (readelf.c:19435)
[1] ==5358== by 0x80868EA: process_file (readelf.c:19588)
[0] ==5358== by 0x8086B01: main (readelf.c:19664)
Скрипт предварительной обработки принимает тестируемый бинарный файл в формате x86 и трассы стека от Valgrind, затем генерирует трейс UAF-ошибки, который представляет собой последовательность целевых местоположений в формате (basic_block_address,function_name), например:
[0] (0x8086ae1,main) -> [1] (0x80868de,process_file) -> [2] (0x808632c,process_archive) ->
[3, alloc] (0x80ad974,make_qualified_name) -> [4, free] (0x808663a,process_archive) ->
[5] (0x808620b,process_archive) -> [6, use] (0x80ab86a,error)
Мы предоставляем шаблон скрипта фаззинга с несколькими входными параметрами, например, фаззер, который мы хотим запустить, тайм-аут в минутах и предопределенные цели (например, извлеченные из отчета об ошибке). Для примера выше мы используем скрипт CVE-2018-20623.sh и запускаем UAFuzz следующим образом:
# Run UAFuzz with timeout 60 minutes
$UAFBENCH_PATH/CVE-2018-20623.sh uafuzz 60 $UAFBENCH_PATH/valgrind/CVE-2018-20623.valgrind
После истечения тайм-аута фаззинга UAFuzz может определить, какие входные данные последовательно покрывают все целевые местоположения ожидаемого трейса UAF-ошибки (например, имя входного файла, заканчивающееся на ',all'). Таким образом, UAFuzz выполняет триаж только тех входных данных, которые с высокой вероятностью вызовут желаемую ошибку, используя существующие инструменты профилирования, такие как Valgrind или AddressSanitizer.
Мы используем CVE-2018-6952 GNU Patch, чтобы проиллюстрировать важность создания различных уникальных входных данных, вызывающих ошибку, для облегчения процесса исправления. В GNU Patch было двойное освобождение, которое было исправлено разработчиками (коммит 9c98635). Однако, используя трассы стека CVE-2018-6952, UAFuzz обнаружил неполное исправление ошибки CVE-2019-20633 в последней версии 2.7.6 (коммит 76e7758), с небольшим отличием в трейсе ошибки. В целом, процесс аналогичен приложению воспроизведения ошибок, за исключением того, что может потребоваться ручная работа по идентификации целевого трейса UAF-ошибки. Мы используем PoC-входные данные существующих ошибок и валидные файлы из fuzzing-corpus в качестве качественных сидов.
# Fuzz patched version of CVE-2018-6952
$UAFBENCH_PATH/CVE-2019-20633.sh uafuzz 360 $UAFBENCH_PATH/valgrind/CVE-2018-6952.valgrind
Возможный гибридный подход — объединить UAFuzz с GUEB, который является единственным статическим анализатором на уровне бинарного кода, написанным на Ocaml для UAF. Однако GUEB выдает много ложных срабатываний и в настоящее время не может корректно работать со сложными бинарными файлами. Поэтому мы сейчас улучшаем и интегрируем GUEB в BINSEC, а затем используем цели, извлеченные из отчетов GUEB, для управления UAFuzz. Следите за обновлениями!