GitHub Security Lab hat einen Open-Source-Workflow namens Fuzzing Taskflow vorgestellt, der große Teile des Testens von C/C++-Projekten mithilfe von Fuzzing und Sprachmodell-Agenten automatisieren soll. Wird er auf ein GitHub-Repository angesetzt, kann der Workflow das Build-System analysieren, geeignete Einstiegspunkte bestimmen, Fuzz-Harnesses erstellen, AFL++ ausführen, Abdeckungsberichte lesen, die Harnesses verbessern, Fehler klassifizieren und für jedes potenzielle Problem einen separaten Bericht erstellen.
Das Projekt basiert auf dem GitHub-Security-Lab-Framework Taskflow Agent, das den Ablauf als eine Gruppe von Workflows beschreibt, die von der Agentin beziehungsweise dem Agenten von Anfang bis Ende ausgeführt werden. Der Autor des Beitrags, Antonio Morales, weist darauf hin, dass das Ziel nicht darin besteht, die Rolle der Forschenden abzuschaffen, sondern zeitaufwendige wiederkehrende Arbeiten an den Agenten zu übertragen, während Entscheidungen und Ausführung in zwei getrennten Schichten verbleiben.
Wie funktioniert der Workflow?
Die Nutzung beginnt im Projekt-Repository, beispielsweise durch die Ausführung des Befehls ./scripts/fuzzing/run_fuzzing.sh PROJECT innerhalb eines Codespaces. Der Workflow installiert die Werkzeuge, klont das Repository, analysiert wichtige Funktionen, erstellt anschließend Fuzzing-Ziele und führt Kampagnen für sie aus. Seine Struktur besteht aus einem Shell-Runner, YAML-Dateien, die die Arbeitsphasen und an das Modell gerichteten Anweisungen beschreiben, sowie MCP-Werkzeugen, die Vorgänge wie das Ausführen von AFL, das Kompilieren der Harnesses, das Lesen der Abdeckung und das Speichern von Fehlern durchführen.
Der Agent ruft AFL oder clang nicht direkt auf. Stattdessen entscheidet er, was getestet werden sollte und welche Abdeckungslücke weiterverfolgt werden sollte, während MCP-Werkzeuge die Operationen auf niedriger Ebene ausführen. Der Zustand wird in einer SQLite-Datenbank namens fuzz_context.db gespeichert. Dadurch können Ergebnisse zwischen den Phasen weitergegeben werden, ohne auf gemeinsam genutzten Speicher angewiesen zu sein.
Schleife zur Verbesserung der Abdeckung
Jeder Harness wird zweimal erstellt: eine .afl-Version zur Steuerung von AFL unter Verwendung geeigneter Instrumentierungswerkzeuge und eine .cov-Version, um die Eingabeliste erneut auszuführen und die Abdeckung von Zeilen und Verzweigungen zu messen. Nach jeder Runde überprüft der Agent die nicht abgedeckten Verzweigungen und wählt anschließend eine Maßnahme aus, etwa das Hinzufügen eines neuen Seeds, die Änderung des Harness-Quellcodes zum Aufruf einer anderen Schnittstelle, die Erweiterung des AFL-Wörterbuchs um von der Codebasis geprüfte Werte oder das Ignorieren eines selten genutzten Pfads, dessen Kosten sich nicht lohnen.
Das Zeitbudget verdoppelt sich von 30 über 60, 120, 240 und 480 auf 960 Sekunden, also bis zu etwa 32 Minuten pro Ziel gemäß der genannten Obergrenze. Der Workflow stoppt, wenn ein Rückgang des Ertrags festgestellt wird: Erzielen zwei aufeinanderfolgende Runden weniger als einen Prozentpunkt Zeilenabdeckung, entsprechend dem konfigurierbaren Standardwert, wechselt er zu einem anderen Ziel.
Umgang mit Eingaben und Fehlern
Der Workflow unterstützt spezielle Mechanismen für JSON-, XML-, reguläre Ausdrucks-, PNG- und binäre TLV-Formate mit eingebetteten Längen. Außerdem kann er aus Zeichenketten- und Zahlenkonstanten in C- und H-Dateien ein Wörterbuch erzeugen. Dieses Wörterbuch wird nach jedem Abdeckungsschritt anhand von Prüfungen in der Nähe der nicht abgedeckten Zeilen erweitert. Zudem besitzt jeder Harness ein festes Corpus-Verzeichnis und verwendet afl-cmin, um dessen Größe zu begrenzen, während nützliche Eingaben zwischen Runden und Kampagnen erhalten bleiben.
Nach Abschluss der Kampagne werden die Fehler mit afl-tmin minimiert und anschließend unter AddressSanitizer erneut ausgeführt. Danach werden Duplikate anhand eines Fingerabdrucks des obersten Stackframes entfernt. Der Workflow testet bekannte Fehler außerdem erneut, um die Auswirkungen von Korrekturen zu überprüfen, und ordnet die Ergebnisse Kategorien zu, darunter: Schwachstelle, Härtung der Bibliothek, Fehler im Harness, Speichermangel, Zeitüberschreitung, Assertion-Fehler oder Duplikat.
Warum ist diese Nachricht wichtig?
Der praktische Wert liegt darin, dass der Workflow versucht, die Schleife zu automatisieren, die die Wirksamkeit kontinuierlichen Fuzzings häufig begrenzt: das Schreiben von Harnesses, das Lesen der Abdeckung, die Auswahl der nächsten Lücke und die Klassifizierung von Fehlern. Dies könnte die Einstiegskosten für das Testen eines Projekts senken, das zuvor noch keinem Fuzzing unterzogen wurde, oder dabei helfen, die Abdeckung eines bestehenden Projekts zu erweitern.
GitHub Security Lab setzt jedoch eine wesentliche Einschränkung: Der Workflow führt afl-fuzz, clang und vom Modell ausgewählte Build-Befehle ohne vorgeschalteten Container direkt auf dem Hostsystem aus. Ein von Prompt-Injection betroffener Agent könnte daher alles ausführen, was der Benutzer ausführen darf. Das Projekt empfiehlt, ihn in einer wegwerfbaren Umgebung wie einem Codespace oder einer temporären virtuellen Maschine und ohne erhöhte Berechtigungen auszuführen.
Auch die Schwachstellenberichte und vorgeschlagenen Korrekturen sind keine endgültigen Ergebnisse. Der Beitrag betont, dass die Analyse des Modells fehlerhaft sein kann und der vorgeschlagene Patch mit dem Hinweis versehen ist, dass er überprüft werden muss. Damit stellt Fuzzing Taskflow einen gut vorbereiteten Ausgangspunkt für Forschende dar, aber keinen Ersatz für die menschliche Überprüfung der Erreichbarkeit, Ausnutzbarkeit und Grundursache.