Fuzzing

Fuzzing, auch Robustness Testing, Fuzzy Testing oder Negative Testing, ist eine automatisierte Technik für Softwaretests, bei der das zu testende Programm an einer oder mehreren Eingabeschnittstellen immer wieder mit Zufallsdaten beschickt wird. Mit zufälligen Daten können meistens Situationen im Betrieb des Programms erzeugt werden, die mit anderen Testverfahren nicht erreicht werden. Programme sind häufig nicht auf beliebige Eingangsdaten ausgelegt und können dann bei nicht plausiblen Daten ungewollt abstürzen und damit auch Sicherheitslücken (engl. Vulnerabilities) offenbaren. Daher ist Fuzzing eine der wichtigsten Techniken von Sicherheitsspezialisten.

QS-Informatik
Beteilige dich an der Diskussion!
 Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+)


Begründung: Bitte den Abschnitt "Werkzeuge/Tools/Software" überarbeiten und Allgemeinverständlich machen --Crazy1880 21:24, 26. Nov. 2010 (CET)

Das Fuzzing (Fuzz-Testing, nach dem englischen Wort fuzzy für „unscharf, verschwommen“) wurde an der Universität von Wisconsin-Madison 1989 von Barton Miller und seinen Studenten entwickelt.[1]

Anwendung

Fuzzing wird in Software-Entwicklungs-Projekten in der Regel im Rahmen eines Black-Box-Tests durchgeführt, um neue Software auf Fehleranfälligkeit zu prüfen sowie um eventuelle Sicherheitslücken aufzuspüren. Mittlerweile wird diese Art des Tests auch manchmal bei Penetration Tests im IT-Security-Bereich durchgeführt, das jedoch eher selten, weil mit Systemabstürzen zu rechnen ist.

Wenn das Programm bei bestimmten vom Fuzzer generierten Daten reproduzierbar ein Problem verursacht (z. B. abstürzt), kann darauf aufbauend anhand von White-Box-Tests die genaue Ursache erforscht werden.

Fuzz-Testing ist recht effektiv, weil der Testprozess in der Regel automatisiert und ohne ein Abbruchkriterium abläuft, weshalb es gerne im Rahmen der Testphase eingesetzt wird. Es wird kein fest definierter Satz von Testfällen abgearbeitet, sondern es werden immer weitere Varianten von Daten generiert. Besteht erst einmal eine Basis (Werkzeuge, Regeln, Abläufe) für das Fuzzing (Fuzz-Testing), können bestehende Fuzz-Tests (Regeln/Sets) sehr schnell und im Rahmen der Entwicklung leicht erweitert werden.

Fuzzing ist eine Methode zur Qualitätssicherung von Software, speziell um noch unbekannte Schwachstellen und Robustheitsprobleme in Software aufzudecken.[2]

Fuzzing-Werkzeuge

Oft werden für das Fuzzing speziell auf das Projekt ausgelegte Tools benötigt und aufgrund dessen oft extra angefertigt/programmiert. Mittlerweile gibt es aber auch – im Gegensatz zu sogenannten „Frameworks“ – erprobte kommerzielle Software. Bei Webanwendungen kann man oft auf bestehende Werkzeuge zurückgreifen, da der Ablauf, abstrahiert dargestellt, immer der gleiche ist und man eine gemeinsame Schnittstelle (HTTP/HTML) hat. Grundsätzlich kann mit Fuzzing-Tools aber alles getestet werden, was eine standardisierte Schnittstelle hat, bzw. alles, was man mit einem Protokoll ansprechen kann.

An diesem Punkt klinken sich Fuzzing-Tools ein. Für das Fuzzing von Browsern und Software gibt es mittlerweile auch gute Werkzeuge. Mit diesen Tools kann man generell Software, wie z. B. Webbrowser, mit zuvor generierten ungültigen Datenstrings/Dateien ansteuern und ungewöhnliches Programmverhalten (z. B. Abstürze, Denial of Service, Degradation of Service) provozieren, ggf. loggen und später auswerten.

Besonders hervorgetan im Bereich Fuzzing hat sich die Security Programmers Group der Universität von Oulu in Finnland. Diese entwickelte bereits 1996 ein bekanntes Open-Source-Fuzzing-Tool mit Namen PROTOS, jedoch wird PROTOS seit 2004 nicht weiter entwickelt. PROTOS ist ein Fuzzer, der mit älteren Techniken arbeitet.[3]

Heute werden im kommerziellen Umfeld mehr und mehr „intelligente“ oder „stateful“ Fuzzer entwickelt, die vorab die Interoperabilität des zu testenden Systems überprüfen und auf Basis der Prüfergebnisse dann das Fuzzing-Testset (anomalisierte Datenpakete) auf das Zielsystem schicken.

Bekannte OpenSource-Frameworks sind hier z. B. Sulley oder Peach. Diese Frameworks sind sehr komplex und benötigen umfangreiche Kenntnisse im Bereich Fuzzing und Protokolle. Andere Tools, wie z. B. Fuzzino, bieten einen Testdatengenerator für Fuzzing, sind leichtgewichtig und daher leicht in bestehende Testwerkzeuge oder einen bestehenden Testprozess zu integrieren. Kommerzielle, intelligente Fuzzing-Tools sind u. a. beSTORM von BeyondSecurity oder Defensics von Codenomicon. Codenomicon’s Defensics arbeitet mit sogenannten „Testcases“, die vordefiniert sind. BeyondSecurity’s „beSTORM“-Fuzzer bedient hingegen jedes Feld im Protokoll mit n×n Anomalien und nicht mit Testcases.

Das Bundesministerium für Bildung und Forschung (BMBF) förderte 2009 ein umfangreiches Forschungsprojekt an der Hochschule Bonn-Rhein-Sieg,[4] in dessen Rahmen mehr als 100 Tools zum Threat Modeling und Fuzzing auf ihre Eignung für Softwaretests getestet und bewertet wurden.

Eine interaktive grafische Übersicht von existierenden Blackbox-, Greybox- und Whitebox-Fuzzern jeweils mit ihrer Abstammung auf fuzzing-survey.org zu sehen.

American Fuzzy Lop

Im Bereich Open-Source-Software hat sich seit 2014 das Fuzzingtool American Fuzzy Lop (kurz afl) von Michał Zalewski durchgesetzt[5][6] (der Name steht für eine Kaninchenrasse). Neben dem eigentlichen Fuzzer afl-fuzz sind weitere Hilfsprogramme z. B. zur Testfallminimierung und Testkorpusminimierung vorhanden. Durch Instrumentierung des Quellcodes des zu testenden Programms (Prüfling) beim Übersetzen kann afl-fuzz später erkennen, welche Blöcke der Software bei einem bestimmten Test-Stimulus durchlaufen werden. Dadurch lässt sich afl der Kategorie der Grey-Box-Fuzzer zuordnen. In Verbindung mit der Erzeugung von Testdaten nach genetischen Methoden, kann der Fuzzer dadurch besser Testdaten generieren, die bei der Bearbeitung zur Ausführung bisher noch nicht benutzter Codeblöcke führen, als andere Fuzzer ohne dieses Verfahren. Dadurch wird nach relativ kurzer Zeit eine vergleichsweise hohe Abdeckung des Codes erreicht.[7] Tatsächlich ist das Verfahren in der Lage, selbständig (d. h. ohne Vorabinformationen) Strukturen in den generierten Daten zu erzeugen.[8] Diese Eigenschaft wird auch genutzt, um Testcorpora (Sammlungen von Testfällen) mit hoher Testabdeckung generieren zu lassen. Vorteile von afl-fuzz sind der automatische Betrieb (mit minimaler, einfacher Konfiguration), Parallelisierbarkeit mit mehreren Kernen oder mehreren Rechnern sowie die hohe Performanz. Zur Einspeisung der Daten wird eine Dateischnittstelle unterstützt, aber zurzeit keine Netzwerkschnittstelle.

Besonders empfindlich reagiert der Prüfling, wenn er mit der Laufzeit-Erweiterung AddressSanitizer kompiliert wurde.[9][10] Diese Erweiterung steht bei den Compilern clang bzw. clang++ und gcc bzw. g++ zur Verfügung und überwacht Speicherzugriffe.

Stehen keine Quelltexte zur Verfügung, so kann afl-fuzz den Prüfling mithilfe von QEMU instrumentieren. Da die Instrumentierung hier nun dynamisch erfolgen muss, ist die Ablaufgeschwindigkeit im Prüfling geringer als bei statisch einkompilierter Instrumentierung.

ClusterFuzz

Im Februar 2019 veröffentlichte Google ClusterFuzz, eine skalierbare Fuzzing-Infrastruktur.

ClusterFuzz wurde entwickelt, um Fehler in Googles Browser Chrome zu finden und deren erfolgreichen Patch zu verifizieren.[11] Seit dem Entwicklungsbeginn 2012 bis Februar 2019 fand ClusterFuzz insgesamt 16.000 Fehler in Google Chrome und 11.000 Fehler in über 160 Projekten, die in OSS-Fuzz integriert waren.[12]

Siehe auch

Literatur

Einzelnachweise
  1. Projektausschreibung der Universität von Wisconsin, Madison 1988 (Projekt 1 ist das Fuzz-Projekt; PDF).
  2. googleonlinesecurity.blogspot.com
  3. ee.oulu.fi
  4. inf.h-brs.de
  5. golem.de
  6. LWN-Artikel zu American Fuzzy Lop (englisch)
  7. White Paper zu American Fuzzy Lop (englisch)
  8. Blog-Eintrag des American Fuzzy Lop-Autors Michał Zalewski (englisch) Hier wird beschrieben, wie sich beim Fuzzen mit American Fuzzy Lop immer komplexere JPEG-Bilder entwickeln
  9. Beispiel zur Erkennung des Heartbleed-Bugs. golem.de
  10. Beispiel für Address Sanitizer. The fuzzing Project (englisch)
  11. Fuzzing for Security. 26. April 2012, abgerufen am 11. Mai 2019 (englisch).
  12. Open sourcing ClusterFuzz. 7. Februar 2019, abgerufen am 11. Mai 2019 (englisch).
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.