Fuzzing

Jedes Programm erwartet Eingaben: eine Datei, eine Zahl, einen Text aus einem Formular. Normalerweise testet man ein Programm mit Eingaben, die Sinn ergeben. Fuzzing macht das Gegenteil. Ein Testwerkzeug erzeugt automatisch Unmengen von Eingaben, die kaputt, absurd oder zufällig sind. Diese wirft es dem Programm hin und beobachtet, was passiert. Stürzt das Programm ab oder verhält es sich seltsam, ist eine Schwachstelle gefunden. Der Name kommt vom englischen „fuzz“, also etwa Rauschen oder Unschärfe.

Warum Zufallsmüll echte Sicherheitslücken findet

Menschen testen Software so, wie sie sie sich vorstellen. Sie geben ein gültiges Datum ein, eine plausible Bilddatei, einen normalen Namen. Genau deshalb übersehen sie die Fälle, an die niemand denkt. Ein Angreifer denkt aber genau daran. Er schickt ein Bild, dessen Größenangabe im Dateikopf gelogen ist, oder einen Namen mit 50.000 Zeichen.

Viele der gefährlichsten Sicherheitslücken entstehen aus solchen unerwarteten Eingaben. Ein bekanntes Muster ist der Pufferüberlauf: Das Programm reserviert Platz für 100 Zeichen, bekommt aber 5.000 und überschreibt damit fremden Speicher. Im günstigen Fall stürzt es nur ab. Im ungünstigen Fall kann ein Angreifer eigenen Code einschleusen und den Rechner übernehmen.

Fuzzing ist deshalb heute Standard bei großen Softwareprojekten. Google betreibt seit Jahren ein Programm namens OSS-Fuzz, das freie Software dauerhaft durchtestet. Es hat dabei bereits über zehntausend Fehler in Projekten wie Browsern, Bildbibliotheken und Verschlüsselungssoftware gefunden. Kein Team von Menschen könnte diese Menge an Tests von Hand leisten.

Vom blinden Raten zum gezielten Mutieren

Die einfachste Form ist reiner Zufall: Das Werkzeug würfelt Bytes zusammen und schickt sie los. Das funktioniert schlecht, weil die meisten Eingaben schon an der ersten Prüfung scheitern. Ein Bildbetrachter verwirft Datenmüll sofort, ohne je in die interessanten Teile des Codes vorzudringen. Man testet dann immer wieder dieselben paar Zeilen.

Moderne Fuzzer arbeiten deshalb mutationsbasiert. Sie starten mit echten, gültigen Beispieldateien und verändern daran nur Kleinigkeiten: ein Byte kippen, eine Zahl verdoppeln, ein Stück löschen. Die Eingabe bleibt dadurch nah genug am Erlaubten, um tief ins Programm zu gelangen, ist aber falsch genug, um es aus dem Tritt zu bringen.

Der wichtigste Trick heißt Coverage-Feedback. Der Fuzzer misst dabei, welche Zeilen des Programms eine Eingabe überhaupt erreicht hat. Eingaben, die neue, bisher unbetretene Stellen im Code auslösen, behält er und verändert sie weiter. Der Rest fliegt raus. So tastet sich das Werkzeug Schritt für Schritt in Bereiche vor, die zufälliges Raten nie erreicht hätte. Das ähnelt einem Schlüsseldienst, der nicht alle Schlüssel durchprobiert, sondern jeden weiterverfolgt, der sich im Schloss ein Stück drehen lässt.

Fuzzing im Alltag von Entwicklern und in den Schlagzeilen

Direkt sichtbar ist Fuzzing für Nutzer nie. Man merkt es indirekt: Browser, Betriebssysteme und Messenger verarbeiten täglich Dateien aus dem Internet, ohne bei jeder kaputten Datei abzustürzen. Ein großer Teil dieser Robustheit stammt aus jahrelangem automatischem Durchtesten. Bei vielen gemeldeten Sicherheitslücken steht in der Meldung selbst, dass sie durch einen Fuzzer entdeckt wurden.

In Firmen läuft Fuzzing meist als Dauerbetrieb auf eigenen Servern, parallel zur normalen Entwicklung. Findet der Fuzzer einen Absturz, erzeugt er automatisch ein Ticket mit der auslösenden Datei. Entwickler können den Fehler damit exakt nachstellen, was bei Zufallsfehlern sonst extrem mühsam wäre.

Neu ist die Kombination mit Sprachmodellen. KI-Systeme schreiben inzwischen die kleinen Hilfsprogramme, die einem Fuzzer zeigen, wie eine Software gefüttert werden muss. Das erschließt Code, für den sich früher niemand die Mühe gemacht hat. Ein häufiger Irrtum bleibt trotzdem bestehen: Fuzzing beweist nie, dass ein Programm sicher ist. Es findet nur Fehler, die es zufällig trifft, und schweigt über alle anderen.