Fuzzing

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
QS-Informatik

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 OMA-Test machen --Crazy1880 21:24, 26. Nov. 2010 (CET)

Fuzzing, auch Robustness Testing oder Negative Testing, ist eine spezielle Technik für Softwaretests. Hierfür werden automatisch mit Tools zufällige Daten erzeugt, die über Eingabeschnittstellen eines Programms verarbeitet werden (z. B. durch Öffnen einer Datei, deren Datenformat das Programm unterstützt). Mit den zufälligen Daten kann der spätere Einsatz simuliert werden, bei dem nicht nur plausible Daten verarbeitet werden müssen, wie es viele, oft unerfahrene Programmierer, annehmen.

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

Anwendung[Bearbeiten]

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.[1]

Fuzzing-Werkzeuge[Bearbeiten]

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 OpenSource Fuzzing Tool mit Namen PROTOS, jedoch wird PROTOS seit 2004 nicht weiter entwickelt. PROTOS ist ein Fuzzer, der mit älteren Techniken arbeitet.[2]

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 ein umfangreiches Forschungsprojekt an der Hochschule Bonn-Rhein-Sieg,[3] in dessen Rahmen mehr als 100 Tools zum Threat Modeling und Fuzzing auf ihre Eignung für Softwaretests getestet und bewertet wurden.

American Fuzzy Lop[Bearbeiten]

Im Bereich OpenSource-Software hat sich seit 2014 das Fuzzingtool American Fuzzy Lop von Michał Zalewski durchgesetzt[4][5] (der Name steht für eine Kaninchenrasse). Durch Instrumentierung des Quellcodes des zu testenden Programms (Prüfling) beim Übersetzen kann der Fuzzer später erkennen, welche Blöcke der Software bei einem bestimmten Test-Stimulus durchlaufen werden. 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[6]. Tatsächlich ist das Verfahren in der Lage, selbständig (d.h. ohne Vorabinformationen) Strukturen in den generierten Daten zu erzeugen[7]. Diese Eigenschaft wird auch genutzt, um Testcorpora (Sammlungen von Testfällen) mit hoher Testabdeckung generieren zu lassen.

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

Siehe auch[Bearbeiten]

Literatur[Bearbeiten]

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. googleonlinesecurity.blogspot.com
  2. ee.oulu.fi
  3. inf.h-brs.de
  4. www.golem.de
  5. LWN-Artikel zu American Fuzzy Lop (englisch)
  6. White Paper zu American Fuzzy Lop (englisch)
  7. 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
  8. www.golem.de
  9. The fuzzing Project (englisch), Beispiel für Address Sanitizer