nccgroup/triforceaflAFL/QEMU-Fuzzing mit Vollsystem-Emulation.
Neu: Für alle, die mit TriforceAFL und TLSF herumspielen möchten, hat Richard Johnson ein Dockerfile erstellt, das beides installiert (und sogar einen Linux-Kernel für euch baut). Es ist hier verfügbar https://hub.docker.com/r/moflow/afl-triforce/tags/.
Ebenfalls neu: afl-tmin funktioniert jetzt mit dem Forkserver!
https://github.com/nccgroup/TriforceAFL Jesse Hertz [email protected] Tim Newsham [email protected]
Dies ist eine gepatchte Version von AFL, die Full-System-Fuzzing mit QEMU unterstützt. Das enthaltene QEMU wurde aktualisiert, um die Verfolgung von Verzweigungen zu ermöglichen, wenn ein Systememulator für x86_64 ausgeführt wird. Es wurden zusätzliche Anweisungen hinzugefügt, um AFLs Forkserver zu starten, Fuzz-Einstellungen vorzunehmen und den Beginn und das Ende von Testfällen zu markieren.
Hinweis: Nicht alle AFL-Werkzeuge wurden mit den neuen Änderungen getestet. Diese Werkzeuge wurden etwas getestet:
Zum Erstellen:
make
So erhaltet ihr eine Coverage-Map:
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
So fuzzt ihr:
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 @@
(Hinweis: Anders als bei Verwendung der Option „-Q" müsst ihr bei Verwendung der Option „-QQ" die vollständige Befehlszeile für afl-qemu-system-trace angeben).
Weitere Einzelheiten zur Verwendung dieser modifizierten Version von AFL findest du in unserem Linux-Syscall-Fuzzer unter https://github.com/nccgroup/TriforceLinuxSyscallFuzzer.
Neue AFL-Flags: -QQ - QEMU in Vollsystem-Emulation anstelle des Benutzermodus (-Q) verwenden
Neue QEMU-Flags: -aflFile - Der Name der Datei, die die Fuzzer-Eingaben enthält -aflPanicAddr - Eine Adresse einer Kernel-Panic-Adresse zur Panikerkennung -aflDmesgAddr - Linux-Kernel-Adresse der dmesg-Logging-Funktion zur Erkennung von Logging und zum Abfangen von Logmeldungen
Neue QEMU-Anweisungen: 0f 24 - aflCall edi=1 startForkserver(esi=enableTicks) Startet den Fork-Server von AFL. Ab diesem Punkt läuft jeder Test in einem separaten, gegabelten Kindprozess. Wenn enableTicks ungleich Null ist, aktiviert QEMU den Timer der CPUs nach dem Forken eines Kindprozesses wieder; ansonsten wird er nicht aktiviert. edi=2 getWork(esi=ptr, edx=sz) Füllt ptr[0..sz] mit dem nächsten Eingabe-Testfall. Gibt die tatsächlich gefüllte Größe zurück (<= sz). edi=3 startWork(esi=ptr) Weist AFL an, mit dem Tracing zu beginnen. Das Argument zeigt auf einen Puffer mit zwei Quadwords, die die Start- und Endadresse des zu verfolgenden Codes angeben. Anweisungen außerhalb dieses Bereichs werden nicht verfolgt. edi=4 doneWork(esi=exitCode) Teilt AFL mit, dass der Testfall abgeschlossen ist. Wenn eine Panik erkannt wird, stoppt AFL den Testfall sofort. Andernfalls läuft er, bis doneWork aufgerufen wird. Der angegebene exitCode wird an AFL zurückgegeben. (Der Code kann – tut es derzeit aber nicht – den Wert 64 per OR in alle Exit-Codes einbeziehen, wenn während des Testfalls dmesg-Logs erkannt wurden.)
Neuer QEMU-Blocktreiber: -drive filename=privmem: Dieser Blocktreiber hält das Abbild des Laufwerks im Copy-on-Write-Speicher, sodass Änderungen nie auf die Festplatte geschrieben werden. Änderungen, die von einem Testfall vorgenommen werden, sind von anderen Testfällen isoliert.
Geschrieben und gepflegt von Michal Zalewski [email protected]
Copyright 2013, 2014, 2015, 2016 Google Inc. All rights reserved. Veröffentlicht unter den Bedingungen der Apache License, Version 2.0.
Für neue Versionen und weitere Informationen siehe: http://lcamtuf.coredump.cx/afl/
Um sich mit anderen Benutzern auszutauschen oder über wichtige neue Funktionen informiert zu werden, sendet eine E-Mail an [email protected].
** Siehe QuickStartGuide.txt, wenn du keine Zeit hast, diese Datei zu lesen. **
Fuzzing ist eine der leistungsfähigsten und bewährtesten Strategien zur Identifizierung von Sicherheitsproblemen in realer Software; es ist verantwortlich für die überwiegende Mehrheit der bislang gefundenen Remote-Codeausführungs- und Privilege-Escalation-Fehler in sicherheitskritischer Software.
Leider ist Fuzzing auch relativ oberflächlich; blinde, zufällige Mutationen machen es sehr unwahrscheinlich, dass bestimmte Codepfade im getesteten Code erreicht werden, wodurch einige Schwachstellen für diese Technik unerreichbar bleiben.
Es gab zahlreiche Versuche, dieses Problem zu lösen. Einer der frühen Ansätze – von Tavis Ormandy entwickelt – ist die Korpus-Destillation. Die Methode verlässt sich auf Coverage-Signale, um eine Teilmenge interessanter Seeds aus einem riesigen, qualitativ hochwertigen Korpus von Kandidatendateien auszuwählen und diese dann mit traditionellen Mitteln zu fuzzen. Dieser Ansatz funktioniert außergewöhnlich gut, erfordert jedoch, dass ein solcher Korpus leicht verfügbar ist. Darüber hinaus liefern Block-Coverage-Messungen nur ein sehr vereinfachtes Verständnis des Programmzustands und sind auf lange Sicht weniger nützlich, um die Fuzzing-Bemühungen zu leiten.
Andere, ausgefeiltere Forschungsarbeiten konzentrierten sich auf Techniken wie Programmflussanalyse („konkolische Ausführung"), symbolische Ausführung oder statische Analyse. Alle diese Methoden sind in experimentellen Umgebungen äußerst vielversprechend, leiden in der praktischen Anwendung jedoch häufig unter Zuverlässigkeits- und Leistungsproblemen – und bieten derzeit keine brauchbare Alternative zu „dummen" Fuzzing-Techniken.
American Fuzzy Lop ist ein Brute-Force-Fuzzer, gekoppelt mit einem überaus einfachen, aber felsenfesten, instrumentierungsgesteuerten genetischen Algorithmus. Er verwendet eine modifizierte Form der Kantenabdeckung, um mühelos subtile, lokale Änderungen im Programmfluss zu erkennen.
Vereinfacht ausgedrückt lässt sich der Gesamtalgorithmus wie folgt zusammenfassen:
Lade die vom Benutzer bereitgestellten anfänglichen Testfälle in die Warteschlange,
Nimm die nächste Eingabedatei aus der Warteschlange,
Versuche, den Testfall auf die kleinste Größe zu reduzieren, die das gemessene Verhalten des Programms nicht verändert,
Mutiere die Datei wiederholt mit einer ausgewogenen und gut recherchierten Auswahl traditioneller Fuzzing-Strategien,
Wenn eine der erzeugten Mutationen zu einem neuen, von der Instrumentierung aufgezeichneten Zustandsübergang geführt hat, füge die mutierte Ausgabe als neuen Eintrag zur Warteschlange hinzu.
Weiter mit 2.
Die entdeckten Testfälle werden außerdem regelmäßig ausgedünnt, um solche zu entfernen, die durch neuere Funde mit höherer Abdeckung überholt wurden; außerdem durchlaufen sie mehrere weitere instrumentierungsgesteuerte Aufwandsminimierungsschritte.
Als Nebenergebnis des Fuzzing-Prozesses erstellt das Werkzeug ein kleines, in sich geschlossenes Korpus interessanter Testfälle. Diese sind äußerst nützlich, um andere arbeits- oder ressourcenintensive Testverfahren zu säen – zum Beispiel für Stresstests von Browsern, Office-Anwendungen, Grafikpaketen oder Closed-Source-Werkzeugen.
Der Fuzzer ist gründlich getestet und bietet sofort einsatzbereite Leistung, die blinder Fuzzing- oder Coverage-only-Werkzeugen weit überlegen ist.
Wenn der Quellcode verfügbar ist, kann die Instrumentierung durch ein Begleitwerkzeug eingefügt werden, das in jedem Standard-Build-Prozess für Drittanbieter-Code als direkter Ersatz für gcc oder clang fungiert.
Die Instrumentierung hat eine relativ geringe Leistungsauswirkung; in Verbindung mit anderen von afl-fuzz implementierten Optimierungen können die meisten Programme genauso schnell oder sogar schneller gefuzzt werden, als dies mit herkömmlichen Werkzeugen möglich ist.
Der korrekte Weg, das Zielprogramm neu zu kompilieren, kann je nach den Besonderheiten des Build-Prozesses variieren, aber ein nahezu universeller Ansatz wäre:
$ CC=/path/to/afl/afl-gcc ./configure $ make clean all
Bei C++-Programmen solltest du auch CXX=/path/to/afl/afl-g++ setzen.
Die Clang-Wrapper (afl-clang und afl-clang++) können auf dieselbe Weise verwendet werden; Clang-Benutzer können sich auch für einen leistungsfähigeren Instrumentierungsmodus entscheiden, wie in llvm_mode/README.llvm beschrieben.
Beim Testen von Bibliotheken musst du ein einfaches Programm finden oder schreiben, das Daten von stdin oder aus einer Datei liest und an die getestete Bibliothek übergibt. In einem solchen Fall ist es wichtig, diese ausführbare Datei gegen eine statische Version der instrumentierten Bibliothek zu linken oder sicherzustellen, dass die richtige .so-Datei zur Laufzeit geladen wird (normalerweise durch Setzen von LD_LIBRARY_PATH). Die einfachste Option ist ein statischer Build, der normalerweise möglich ist über:
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared
Das Setzen von AFL_HARDEN=1 beim Aufruf von 'make' bewirkt, dass der CC-Wrapper automatisch Code-Härtungsoptionen aktiviert, die das Erkennen einfacher Speicherfehler erleichtern.
PS. ASAN-Benutzern wird empfohlen, die Datei notes_for_asan.txt auf wichtige Einschränkungen zu prüfen.
Wenn der Quellcode NICHT verfügbar ist, bietet der Fuzzer experimentelle Unterstützung für schnelle, On-the-fly-Instrumentierung von Black-Box-Binärdateien. Dies wird mit einer Version von QEMU erreicht, die im weniger bekannten Modus „Userspace-Emulation" läuft.
QEMU ist ein separates Projekt neben AFL, aber du kannst das Feature bequem erstellen, indem du Folgendes ausführst:
$ cd qemu_mode $ ./build_qemu_support.sh
Weitere Anweisungen und Einschränkungen findest du in qemu_mode/README.qemu.
Dieser Modus ist etwa 2-5x langsamer als Compile-Zeit-Instrumentierung, eignet sich weniger für Parallelisierung und kann einige andere Eigenheiten aufweisen.
Um korrekt zu arbeiten, benötigt der Fuzzer eine oder mehrere Ausgangsdateien, die ein gutes Beispiel der Eingabedaten enthalten, die die Zielanwendung normalerweise erwartet. Es gibt zwei grundlegende Regeln:
Halte die Dateien klein. Unter 1 kB ist ideal, wenn auch nicht unbedingt erforderlich. Eine Erläuterung, warum die Größe wichtig ist, findest du in perf_tips.txt.
Verwende mehrere Testfälle nur, wenn sie sich funktional voneinander unterscheiden. Es hat keinen Sinn, fünfzig verschiedene Urlaubsfotos zu verwenden, um eine Bildbibliothek zu fuzzen.
Viele gute Beispiele für Ausgangsdateien findest du im Unterverzeichnis testcases/, das diesem Werkzeug beiliegt.
PS. Wenn ein großer Datenkorpus zum Durchsuchen verfügbar ist, möchtest du möglicherweise das Dienstprogramm afl-cmin verwenden, um eine Teilmenge funktional unterschiedlicher Dateien zu identifizieren, die verschiedene Codepfade im Zielbinary durchlaufen.
Der Fuzzing-Prozess selbst wird vom Dienstprogramm afl-fuzz durchgeführt. Dieses Programm benötigt ein schreibgeschütztes Verzeichnis mit anfänglichen Testfällen, einen separaten Ort zum Speichern seiner Ergebnisse sowie einen Pfad zum zu testenden Binary.
Für Ziel-Binaries, die Eingaben direkt von stdin akzeptieren, lautet die übliche Syntax:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]
Bei Programmen, die Eingaben aus einer Datei lesen, verwende '@@', um in der Befehlszeile des Ziels die Stelle zu markieren, an der der Name der Eingabedatei platziert werden soll. Der Fuzzer ersetzt dies für dich:
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@
Du kannst auch die Option -f verwenden, um die mutierten Daten in eine bestimmte Datei schreiben zu lassen. Dies ist nützlich, wenn das Programm eine bestimmte Dateierweiterung oder Ähnliches erwartet.
Nicht instrumentierte Binaries können im QEMU-Modus (füge -Q in der Befehlszeile hinzu) oder in einem traditionellen Blind-Fuzzer-Modus (mit -n) gefuzzt werden.
Du kannst -t und -m verwenden, um das Standard-Timeout und das Speicherlimit für den ausgeführten Prozess zu überschreiben; seltene Beispiele für Zielprogramme, bei denen diese Einstellungen angepasst werden müssen, sind Compiler und Videodecoder.
Tipps zur Optimierung der Fuzzing-Leistung werden in perf_tips.txt erörtert.
Beachte, dass afl-fuzz zunächst eine Reihe deterministischer Fuzzing-Schritte durchführt, die mehrere Tage dauern können. Wenn du schnelle & schmutzige Ergebnisse sofort möchtest, ähnlich wie bei zzuf oder honggfuzz, füge die Option -d zur Befehlszeile hinzu.
Siehe die Datei status_screen.txt für Informationen zur Interpretation der angezeigten Statistiken und zur Überwachung des Zustands des Prozesses. Konsultiere diese Datei unbedingt, insbesondere wenn UI-Elemente rot hervorgehoben sind.
Der Fuzzing-Prozess läuft weiter, bis du Ctrl-C drückst. Mindestens solltest du dem Fuzzer erlauben, einen Warteschlangenzyklus abzuschließen, was zwischen ein paar Stunden und etwa einer Woche dauern kann.
Im Ausgabeverzeichnis werden drei Unterverzeichnisse erstellt und in Echtzeit aktualisiert:
queue/ - Testfälle für jeden charakteristischen Ausführungspfad, plus alle vom Benutzer angegebenen Startdateien. Dies ist das synthetisierte Korpus, das in Abschnitt 2 erwähnt wird.
Bevor du dieses Korpus für andere Zwecke verwendest, kannst du es
mit dem Werkzeug afl-cmin auf eine kleinere Größe reduzieren. Das
Werkzeug findet eine kleinere Teilmenge von Dateien mit äquivalenter
Kantenabdeckung.
crashes/ - eindeutige Testfälle, die dazu führen, dass das getestete Programm ein fatales Signal empfängt (z. B. SIGSEGV, SIGILL, SIGABRT). Die Einträge sind nach dem empfangenen Signal gruppiert.
hangs/ - eindeutige Testfälle, die dazu führen, dass das getestete Programm ein Timeout erleidet. Beachte, dass dies bei den standardmäßigen (aggressiven) Timeout-Einstellungen aufgrund von Latenzspitzen und anderen natürlichen Phänomenen etwas verrauscht sein kann.
Crashes und Hangs gelten als „eindeutig", wenn die zugehörigen Ausführungspfade Zustandsübergänge beinhalten, die bei zuvor aufgezeichneten Fehlern nicht gesehen wurden. Wenn ein einzelner Fehler auf mehreren Wegen erreichbar ist, kommt es früh im Prozess zu einer gewissen Zählinflation, die aber schnell abklingen sollte.
Die Dateinamen für Crashes und Hangs sind mit den übergeordneten, fehlerfreien Warteschlangeneinträgen korreliert. Das sollte beim Debuggen helfen.
Wenn du einen von afl-fuzz gefundenen Crash nicht reproduzieren kannst, ist die wahrscheinlichste Ursache, dass du nicht dasselbe Speicherlimit wie das Werkzeug setzt. Versuche:
$ LIMIT_MB=50 $ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )
Ändere LIMIT_MB so, dass es dem an afl-fuzz übergebenen Parameter -m entspricht. Ändere unter OpenBSD außerdem -Sv in -Sd.
Ein vorhandenes Ausgabeverzeichnis kann auch verwendet werden, um abgebrochene Jobs fortzusetzen; versuche:
$ ./afl-fuzz -i- -o existing_output_dir [...etc...]
Wenn gnuplot installiert ist, kannst du mit afl-plot auch hübsche Graphen für jede aktive Fuzzing-Aufgabe erzeugen. Ein Beispiel dafür findest du unter http://lcamtuf.coredump.cx/afl/plot/.
Jede Instanz von afl-fuzz belegt ungefähr einen Kern. Das bedeutet, dass auf Mehrkernsystemen Parallelisierung notwendig ist, um die Hardware voll auszulasten. Tipps zum Fuzzing eines gemeinsamen Ziels auf mehreren Kernen oder mehreren vernetzten Maschinen findest du in parallel_fuzzing.txt.
Standardmäßig ist die Mutations-Engine von afl-fuzz für kompakte Datenformate optimiert – etwa Bilder, Multimedia, komprimierte Daten, reguläre Ausdrücke oder Shell-Skripte. Sie ist etwas weniger geeignet für Sprachen mit besonders ausführlichem und redundantem Wortschatz – insbesondere HTML, SQL oder JavaScript.
Um den Aufwand für den Bau syntaxbewusster Werkzeuge zu vermeiden, bietet afl-fuzz eine Möglichkeit, den Fuzzing-Prozess mit einem optionalen Wörterbuch aus Sprachschlüsselwörtern, Magic Headern oder anderen speziellen Token zu versorgen, die mit dem Ziel-Datentyp verbunden sind – und damit die zugrunde liegende Grammatik spontan zu rekonstruieren:
http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html
Um diese Funktion zu nutzen, musst du zuerst ein Wörterbuch in einem der beiden Formate erstellen, die in testcases/README.testcases besprochen werden; und dann den Fuzzer über die Option -x in der Befehlszeile darauf zeigen lassen.
Es gibt keine Möglichkeit, strukturiertere Beschreibungen der zugrunde liegenden Syntax bereitzustellen, aber der Fuzzer wird wahrscheinlich einiges davon allein auf der Grundlage des Instrumentierungs-Feedbacks herausfinden. Das funktioniert in der Praxis tatsächlich, siehe:
http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html
PS. Selbst wenn kein explizites Wörterbuch angegeben wird, versucht afl-fuzz, vorhandene Syntax-Tokens im Eingabekorpus zu extrahieren, indem es die Instrumentierung während deterministischer Byte-Flips sehr genau beobachtet. Das funktioniert für einige Arten von Parsern und Grammatiken, ist aber bei weitem nicht so gut wie der -x-Modus.
Die coverage-basierte Gruppierung von Crashes erzeugt normalerweise einen kleinen Datensatz, der schnell manuell oder mit einem sehr einfachen GDB- oder Valgrind-Skript triagiert werden kann. Jeder Crash ist außerdem auf seinen übergeordneten, nicht abstürzenden Testfall in der Warteschlange zurückführbar, was die Diagnose von Fehlern erleichtert.
Abgesehen davon ist es wichtig anzuerkennen, dass einige Fuzzing-Crashes ohne viel Debugging- und Codeanalysearbeit nur schwer schnell auf ihre Ausnutzbarkeit hin bewertet werden können. Um diese Aufgabe zu unterstützen, bietet afl-fuzz einen sehr einzigartigen Modus zur „Crash-Erkundung", der mit dem Flag -C aktiviert wird.
In diesem Modus nimmt der Fuzzer einen oder mehrere abstürzende Testfälle als Eingabe und verwendet seine feedbackgesteuerten Fuzzing-Strategien, um sehr schnell alle Codepfade aufzulisten, die im Programm erreicht werden können, während es im abstürzenden Zustand gehalten wird.
Mutationen, die nicht zu einem Absturz führen, werden verworfen; ebenso Änderungen, die den Ausführungspfad nicht beeinflussen.
Die Ausgabe ist ein kleines Korpus von Dateien, das sehr schnell untersucht werden kann, um zu sehen, welches Maß an Kontrolle der Angreifer über die fehlerverursachende Adresse hat oder ob es möglich ist, anfängliche Out-of-Bounds-Reads zu überwinden – und zu sehen, was darunter liegt.
Oh, noch etwas: Für die Testfallminimierung solltest du afl-tmin ausprobieren. Das Werkzeug kann auf sehr einfache Weise bedient werden:
$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]
Das Werkzeug funktioniert mit abstürzenden und nicht abstürzenden Testfällen gleichermaßen. Im Crash-Modus akzeptiert es bereitwillig instrumentierte und nicht instrumentierte Binaries. Im Nicht-Crash-Modus verlässt sich der Minimierer auf die Standard-AFL-Instrumentierung, um die Datei zu vereinfachen, ohne den Ausführungspfad zu verändern.
Der Minimierer akzeptiert die Syntax -m, -t, -f und @@ in einer mit afl-fuzz kompatiblen Weise.
Eine weitere kürzliche Ergänzung zu AFL ist das Werkzeug afl-analyze. Es nimmt eine Eingabedatei, versucht sequenziell Bytes zu kippen und beobachtet das Verhalten des getesteten Programms. Anschließend färbt es die Eingabe basierend darauf ein, welche Abschnitte kritisch erscheinen und welche nicht; es ist zwar nicht wasserdicht, kann aber oft schnelle Einblicke in komplexe Dateiformate bieten. Weitere Informationen zu seiner Funktionsweise finden sich gegen Ende von technical_details.txt.
Bitte denke daran, dass Fuzzing – ähnlich wie viele andere rechenintensive Aufgaben – deine Hardware und das Betriebssystem belasten kann. Insbesondere:
Deine CPU wird heiß laufen und benötigt ausreichende Kühlung. In den meisten Fällen werden die CPU-Geschwindigkeiten automatisch gedrosselt, wenn die Kühlung unzureichend ist oder nicht mehr richtig funktioniert. Das heißt jedoch, dass es – insbesondere beim Fuzzing auf weniger geeigneter Hardware (Laptops, Smartphones usw.) – nicht völlig unmöglich ist, dass etwas durchbrennt.
Zielprogramme können unvorhersehbar Gigabyte an Speicher beanspruchen oder die Festplatte mit Junk-Dateien füllen. AFL versucht, grundlegende Speicherlimits durchzusetzen, kann aber nicht jedes mögliche Missgeschick verhindern. Das Fazit ist, dass du nicht auf Systemen fuzzen solltest, auf denen die Aussicht auf Datenverlust kein akzeptables Risiko ist.- Fuzzing beinhaltet Milliarden von Lese- und Schreibzugriffen auf das Dateisystem. Auf modernen Systemen wird dies normalerweise stark gecacht, was zu recht geringer "physischer" I/O führt - aber es gibt viele Faktoren, die diese Gleichung verändern können. Es liegt in Ihrer Verantwortung, auf mögliche Probleme zu achten; bei sehr starker I/O kann die Lebensdauer vieler HDDs und SSDs verkürzt werden.
Eine gute Möglichkeit, die Disk-I/O unter Linux zu überwachen, ist der Befehl 'iostat':
$ iostat -d 3 -x -k [...optional disk ID...]
Hier sind einige der wichtigsten Hinweise für AFL:
AFL erkennt Fehler, indem es prüft, ob der erste gestartete Prozess aufgrund eines Signals stirbt (SIGSEGV, SIGABRT usw.). Programme, die eigene Handler für diese Signale installieren, müssen den entsprechenden Code möglicherweise auskommentieren. Ebenso können Fehler in Kindprozessen, die vom gefuzzten Zielprozess gestartet werden, der Erkennung entgehen, sofern Sie nicht manuell Code hinzufügen, um diese abzufangen.
Wie bei jedem anderen Brute-Force-Werkzeug bietet der Fuzzer nur eine begrenzte Abdeckung, wenn Verschlüsselung, Prüfsummen, kryptografische Signaturen oder Komprimierung verwendet werden, um das eigentliche zu testende Datenformat vollständig zu umhüllen.
Um dies zu umgehen, können Sie die entsprechenden Prüfungen auskommentieren (siehe experimental/libpng_no_checksum/ als Anregung); falls dies nicht möglich ist, können Sie auch einen Postprozessor schreiben, wie in experimental/post_library/ erläutert.
Mit ASAN und 64-Bit-Binaries sind einige unglückliche Kompromisse verbunden. Das liegt nicht an einem spezifischen Fehler von afl-fuzz; siehe notes_for_asan.txt für Tipps.
Es gibt keine direkte Unterstützung für das Fuzzing von Netzwerkdiensten, Hintergrund-Daemons oder interaktiven Anwendungen, die eine UI-Interaktion erfordern. Möglicherweise müssen Sie einfache Codeänderungen vornehmen, damit sie sich auf traditionellere Weise verhalten. Preeny bietet möglicherweise auch eine relativ einfache Option - siehe: https://github.com/zardus/preeny
Einige nützliche Tipps zur Anpassung netzwerkbasierter Dienste finden Sie außerdem unter: https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
AFL gibt keine menschenlesbaren Coverage-Daten aus. Wenn Sie die Coverage überwachen möchten, verwenden Sie afl-cov von Michael Rash: https://github.com/mrash/afl-cov
Darüber hinaus siehe INSTALL für plattformspezifische Tipps.
Viele der Verbesserungen an afl-fuzz wären ohne Feedback, Fehlerberichte oder Patches der folgenden Personen nicht möglich:
Jann Horn Hanno Boeck Felix Groebert Jakub Wilk Richard W. M. Jones Alexander Cherepanov Tom Ritter Hovik Manucharyan Sebastian Roschke Eberhard Mattes Padraig Brady Ben Laurie @dronesec Luca Barbato Tobias Ospelt Thomas Jarosch Martin Carpenter Mudge Zatko Joe Zbiciak Ryan Govostes Michael Rash William Robinet Jonathan Gray Filipe Cabecinhas Nico Weber Jodie Cunningham Andrew Griffiths Parker Thompson Jonathan Neuschfer Tyler Nighswander Ben Nagy Samir Aguiar Aidan Thornton Aleksandar Nikolich Sam Hakim Laszlo Szekeres David A. Wheeler Turo Lamminen Andreas Stieger Richard Godbee Louis Dassy teor2345 Alex Moneger Dmitry Vyukov Keegan McAllister Kostya Serebryany Richo Healey Martijn Bogaard rc0r Jonathan Foote Christian Holler Dominique Pelle Jacek Wielemborek Leo Barnes Jeremy Barnes Jeff Trull Guillaume Endignoux ilovezfs Daniel Godas-Lopez Franjo Ivancic
Danke!
Fragen? Bedenken? Fehlerberichte? Der Autor ist in der Regel unter [email protected] erreichbar.
Es gibt auch eine Mailingliste für das Projekt; um beizutreten, senden Sie eine E-Mail an [email protected]. Oder, wenn Sie zuerst in den Archiven stöbern möchten, versuchen Sie:
https://groups.google.com/group/afl-users
PS. Wenn Sie rohen Code einreichen möchten, der in das Projekt aufgenommen werden soll, beachten Sie bitte, dass Google das Urheberrecht am größten Teil von AFL beansprucht. Während Sie das Urheberrecht an Ihren Beiträgen behalten, bittet Google die Leute jedoch, zuerst einer einfachen CLA zuzustimmen:
https://cla.developers.google.com/clas
Entschuldigung für die Umstände. Natürlich ist für Feature-Anfragen oder Fehlerberichte keine CLA erforderlich.