Schwachstellensuche mit Fuzzing

Seite 3: Strukturerkennung

Strukturerkennung

Der Sicherheitsexperte Dan Kaminski beschrieb in seinem Vortrag "Black Ops 2006" auf dem Chaos Communications Congress in Berlin [5] einen Ansatz für ein intelligentes Fuzzing, das ohne aufwändige blockbasierte Protokollanalyse auskommt und trotzdem die Datenstruktur berücksichtigt. Die Grundidee ist, die Struktur der zu fuzzenden Daten mit Hilfe eines geeigneten Algorithmus zu erkennen, um diese beim Fuzzing vorwiegend intakt zu lassen.

Kaminski verwendete den Kompressionsalgorithmus Sequitur [6], der Eingabedaten in eine Grammatik (die Struktur) und ein Wörterbuch (die Nutzdaten) zerlegt. Sein bislang noch unausgereifter Proof-of-Concept-Fuzzer CFG9000 (Context Free Grammar Fuzzer) [7] ist auf dieser Basis in der Lage, beispielsweise ein HTML-Dokument derart durcheinanderzuwürfeln, dass Browser es trotz seiner offensichtlichen Defekte meist noch irgendwie darstellen. Ein Verständnis des HTML-Protokolls ist dafür nicht nötig – der Fuzzer arbeitet mit beliebigen Daten.

Lebt es noch?

Fuzzing-Beispiel heise.de — Das Context Free Grammar Fuzzing liefert auch ohne HTML-Blockanalyse eine Seite, die irgendwie immer noch nach heise.de aussieht.

Ein wesentliches Problem beim Fuzzing ist, zuverlässig das Auftreten eines Programmfehlers festzustellen. Läuft das Programm auf einem Rechner, zu dem der Tester direkten Zugang hat, gibt es vielfältige Möglichkeiten. Eine gängige Methode ist das Anhängen eines Debuggers wie IDA Pro oder Ollydbg unter Windows beziehungsweise gdb unter Linux an den laufenden Prozess. Kommt es während des Fuzzing zu einer Zugriffsverletzung, fängt sie der Debugger sofort für weitere Analysen ab.

Außerdem geben eine sprunghaft ansteigende CPU- oder Speicherauslastung Hinweise darauf, dass der Fuzzer einen Programmierfehler erwischt hat. Dazu lassen sich die gängigen Betriebssystemtools oder spezielle Testprogramme wie Valgrind für Speicher-Leaks einsetzen. Tracing, also das schrittweise Protokollieren des Programmablaufs, ist oft nicht praktikabel, weil es die zu testenden Programme in der Regel stark verlangsamt.

Ohne direkten Zugriff auf den Rechner mit dem Untersuchungsobjekt versagen jedoch diese Methoden völlig. Bei einem solchen Black-Box-Fuzzing lässt aber der mitprotokollierte Netzwerkverkehr unter Umständen brauchbare Rückschlüsse zu. Registriert der Tester ungewöhnliche oder völlig ausbleibende Antwortpakete oder ist der Dienst längere Zeit nicht erreichbar, ist er möglicherweise abgestürzt.

Manche Fuzzing-Frameworks wurden speziell für diese Zwecke entwickelt. Autodafe beispielsweise bietet spezielle Funktionen, um mit Hilfe von Debuggern und Tracern die Reaktionen der zu untersuchenden Programme auf die präsentierten Eingabedaten zu analysieren. Allerdings ist dies noch ein relativ junges Forschungsgebiet.

Praxisprobleme

Tester stoßen beim Fuzzing aber auch auf andere, typische Praxisprobleme. Gelegentlich verbergen sich kritische Programmierfehler hinter anderen, lapidaren Fehlern, die das Programm beispielsweise vorher abstürzen lassen. Außerdem können die vielen Datenmüllberge aufgrund von eher harmlosen Memory-Leaks in den Programmen den verfügbaren Arbeitsspeicher in kurzer Zeit aufbrauchen. Unter Umständen sind häufige System-Reboots die Folge. Grafische Bedienoberflächen wie die von Browsern können mit aufpoppenden Dialogfenstern ebenfalls Steine in den Weg des Testers rollen.

Umgehungsmöglichkeiten wie Apples Skripting-Sprache Applescript, mit der sich Tastatur- und Mauseingaben teilweise automatisieren lassen, bieten häufig nur unzureichende Funktionen oder sind auf anderen Systemen gar nicht erst verfügbar. Testern bleibt in solchen Fällen meist nur der Griff zum Editor oder zum Debugger, um die Probleme im Quellcode oder durch umständliches Patchen des Binärprogramms aus dem Weg zu räumen.

Wohin es geht

Die Popularität des Fuzzing ist in den vergangenen Jahren sprunghaft angestiegen, was sich gut an der wachsenden Zahl der hoch spezialisierten Fuzzing-Tools ablesen lässt. Einige der Tools lassen sich bereits ohne fundierte technische Kenntnisse einsetzen. Dementsprechend häufen sich in letzter Zeit auf einschlägigen Mailinglisten vermeintliche Sicherheits-Advisories, die deutlich erkennen lassen, dass der Poster den Fehlern mit Fuzzing auf die Spur gekommen ist. Frei nach dem Strickmuster "Programm X in Version Y stürzt ab, wenn man eine Datei mit Inhalt Z öffnet" fehlt ihnen jeglicher Tiefgang, und oft lassen sie selbst Sicherheitsexperten über tatsächliche Auswirkungen und geeignete Gegenmaßnahmen im Dunkeln.

Bislang gibt es erst für wenige Protokolle und Formate spezielle Fuzzing-Tools und in vielen Bereichen besteht noch Forschungsbedarf. Obwohl das Fuzzing noch in den Kinderschuhen steckt, ist es bereits überaus erfolgreich. Dass noch viel Raum für neue Ideen und verbesserungen besteht, haben neuere Ansätze wie das Context Free Grammar Fuzzing gezeigt. Programmierfehler werden nun am laufenden Band entdeckt. Doch weil die ohnehin ausgelasteten Entwickler mit der Behebung gemeldeter Schwachstellen kaum nachkommen, macht es die Computerwelt zurzeit keinesfalls sicherer.

Solange Softwarefirmen durch die Sicherheit der eigenen Produkte kein unmittelbarer finanzieller Vorteil entsteht, werden sie in der Regel keine zusätzlichen Kapazitäten für die Behebung von Sicherheitslücken bereitstellen. Eine wünschenswerte Entwicklung für die Zukunft wäre, dass die Firmen ihr Know-how nutzen, um effizientes Fuzzing als festen Bestandteil ihrer Qualitätssicherung zu etablieren.

Fuzzing ist ein äußerst mächtiges Werkzeug, mit dem Experten in kürzester Zeit ungeahnte Fehlerquellen aufspüren können – nicht mehr, aber auch nicht weniger. Um die aufgedeckten Schwachstellen zu analysieren und deren Tragweite beispielsweise mit funktionsfähigen Exploits zu verdeutlichen, braucht es nach wie vor viele helle Köpfe.