strongcourage/uafuzzUAFuzz: Binärebene-gesteuertes Fuzzing für Use-After-Free-Schwachstellen
Gerichtetes Greybox-Fuzzing (DGF) wie AFLGo zielt darauf ab, Stresstests an vorausgewählten potenziell verwundbaren Zielstellen durchzuführen, mit Anwendungen in verschiedenen Sicherheitskontexten: (1) Bug-Reproduktion, (2) Patch-Testing oder (3) Überprüfung von Static-Analysis-Berichten. In letzter Zeit gibt es weitere Forschungsarbeiten, die die Effektivität und Effizienz des gerichteten Fuzzings verbessert haben (siehe awesome-directed-fuzzing).
Wir schlagen UAFuzz vor, einen auf Use-After-Free (UAF)-Fehler auf Binärebene spezialisierten gerichteten Fuzzer, der die Schlüsselkomponenten des gerichteten Fuzzings sorgfältig an die spezifischen Merkmale dieser Fehlerklasse anpasst. UAF-Fehler treten auf, wenn ein Heap-Element nach seiner Freigabe noch verwendet wird. Die Erkennung von UAF-Fehlern ist schwierig: (1) Komplexität, da ein Proof-of-Concept (PoC)-Input eine Sequenz von drei Ereignissen – Allok, Free und Use – an derselben Speicherstelle auslösen muss, die sich über mehrere Funktionen des getesteten Programms erstreckt, und (2) Stille ohne Segmentation Fault.
Insgesamt hat UAFuzz einen ähnlichen Workflow wie gerichtete Fuzzer, wobei unsere Modifikationen im gesamten Fuzzing-Prozess orange hervorgehoben sind, wie in der folgenden Abbildung dargestellt. Da wir uns auf (1) Bug-Reproduktion und (2) Patch-Testing-Anwendungen konzentrieren, ist es wahrscheinlicher, dass wir (meistens) vollständige Stack Traces aller speicherbezogenen UAF-Ereignisse haben. Im Gegensatz zu bestehenden allgemeinen gerichteten Ansätzen, bei denen Ziele unabhängig ausgewählt werden können, berücksichtigen wir die Beziehung zwischen den Zielen (z. B. die Reihenfolge, die für UAFs wesentlich ist), um die Gerichtetheit zu verbessern. Erstens ist die statische Vorausberechnung von UAFuzz schnell auf Binärebene. Zweitens führen wir neue reihenfolgebewusste Input-Metriken ein, um den Fuzzer zur Laufzeit auf die Ziele zu lenken. Schließlich sichten wir nur potenzielle Eingaben, die alle Ziele in der erwarteten Ablaufverfolgung abdecken, und filtern Eingaben vor, die weniger wahrscheinlich den Fehler auslösen.
Weitere Details in unserem Paper auf der RAID'20 und unserem Talk auf der Black Hat USA'20. Dank auch an Sébastien Bardin, Matthieu Lemerre, Prof. Roland Groz und insbesondere Richard Bonichon (@rbonichon) für seine Hilfe bei Ocaml.
Unsere getestete Umgebung ist 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
Unser Fuzzer basiert auf AFL v2.52b im QEMU-Modus für das Fuzzing und BINSEC für leichte statische Analysen (siehe uafuzz/README.md). Derzeit verwenden wir IDA Pro v6.9, um Kontrollflussgraphen (CFGs) und den Call-Graphen der getesteten Binärdatei zu extrahieren (siehe 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
Wir betrachten zunächst einen einfachen UAF-Fehler. Sowohl AFL-QEMU als auch der gerichtete Fuzzer AFLGo mit Zielen auf Quellcodeebene können diesen Fehler innerhalb von 6 Stunden nicht erkennen, während UAFuzz ihn mit Hilfe eines Valgrind-UAF-Berichts innerhalb von Minuten erkennen kann.
# 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
Für reale Programme verwenden wir das UAF Fuzzing Benchmark für unsere Bewertungen.
# Checkout the benchmark
git clone https://github.com/strongcourage/uafbench.git
cd uafbench; export UAFBENCH_PATH=`pwd`
Wir zeigen im Detail, wie man UAFuzz für die Bug-Reproduktion von CVE-2018-20623 von readelf (Binutils) ausführt. Die Stack Traces dieses UAF-Fehlers, die mit Valgrind ermittelt wurden, sind wie folgt:
// 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)
Das Vorverarbeitungsskript nimmt die getestete Binärdatei in x86 und die Valgrind-Stack-Traces als Eingaben und erzeugt dann die UAF-Fehlerverfolgung, die eine Sequenz von Zielorten im Format (basic_block_address,function_name) ist, wie folgt:
[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)
Wir stellen eine Fuzzing-Skriptvorlage mit mehreren Eingabeparametern zur Verfügung, z. B. den auszuführenden Fuzzer, das Timeout in Minuten und die vordefinierten Ziele (z. B. aus dem Bug-Report extrahiert). Für das obige Beispiel verwenden wir das Skript CVE-2018-20623.sh und führen UAFuzz wie folgt aus:
# Run UAFuzz with timeout 60 minutes
$UAFBENCH_PATH/CVE-2018-20623.sh uafuzz 60 $UAFBENCH_PATH/valgrind/CVE-2018-20623.valgrind
Nach dem Fuzzing-Timeout kann UAFuzz identifizieren, welche Eingaben der Reihe nach alle Zielorte der erwarteten UAF-Fehlerverfolgung abdecken (z. B. Eingabename, der mit ,all endet). Daher sichtet UAFuzz nur diese Arten von Eingaben, die wahrscheinlich den gewünschten Fehler auslösen, indem es vorhandene Profiling-Tools wie Valgrind oder AddressSanitizer verwendet.
Wir verwenden CVE-2018-6952 von GNU Patch, um die Bedeutung der Erzeugung unterschiedlicher, eindeutiger fehlerauslösender Eingaben zur Unterstützung des Reparaturprozesses zu veranschaulichen. Es gab einen Double-Free in GNU Patch, der von den Entwicklern behoben wurde (Commit 9c98635). Mithilfe der Stack Traces von CVE-2018-6952 entdeckte UAFuzz jedoch eine unvollständige Fehlerbehebung CVE-2019-20633 der neuesten Version 2.7.6 (Commit 76e7758) mit einem geringfügigen Unterschied in der Fehlerverfolgung. Insgesamt ist der Prozess ähnlich wie bei der Bug-Reproduktion, mit der Ausnahme, dass möglicherweise manuelle Arbeit erforderlich ist, um die Ziel-UAF-Fehlerverfolgung zu identifizieren. Wir verwenden PoC-Eingaben vorhandener Fehler und gültiger Dateien aus fuzzing-corpus als qualitativ hochwertige Seeds.
# Fuzz patched version of CVE-2018-6952
$UAFBENCH_PATH/CVE-2019-20633.sh uafuzz 360 $UAFBENCH_PATH/valgrind/CVE-2018-6952.valgrind
Ein möglicher hybrider Ansatz besteht darin, UAFuzz mit GUEB zu kombinieren, dem einzigen in Ocaml geschriebenen binärlevel-statischen Analyzer für UAF. GUEB produziert jedoch viele False Positives und kann derzeit nicht richtig mit komplexen Binärdateien arbeiten. Daher verbessern und integrieren wir GUEB derzeit in BINSEC und verwenden dann die aus GUEB-Berichten extrahierten Ziele, um UAFuzz zu leiten. Bleiben Sie gespannt!