Abo
  • Services:
Anzeige
American Fuzzy Lop kann Bugs wie Heartbleed finden.
American Fuzzy Lop kann Bugs wie Heartbleed finden. (Bild: Screenshot)

Fuzzing des TLS-Handshakes

Damit kann der Fuzzing-Vorgang beginnen. Die letzte für Heartbleed anfällige OpenSSL-Version ist 1.0.1f. Diese muss mit Hilfe von American Fuzzy Lop kompiliert werden; dafür müssem in der Makefile die Aufrufe von gcc durch afl-gcc ersetzt werden. Um Address Sanitizer zu aktivieren, muss vorher die Umgebungsvariable AFL_USE_ASAN auf 1 gesetzt werden (AFL_USE_ASAN=1; export AFL_USE_ASAN).

Anschließend wird das Test-Tool selftls mit American Fuzzy Lop kompiliert und statisch gegen OpenSSL gelinkt. Der OpenSSL-Compile erzeugt hierfür zwei Dateien libssl.a und libcrypto.a, die wir dafür nutzen:

Anzeige

afl-gcc selftls.c -o selftls libssl.a libcrypto.a -ldl

Ein einfacher Aufruf des Test-Tools führt dazu, dass sechs Dateien mit den Namen packet-1 bis packet-6 erstellt werden. Nur die Pakete eins bis vier enthalten Daten, die letzten beiden sind leer. Nur der initiale Teil des Handshakes soll gefuzzt werden. Durch den Aufruf von ./selftls 1 packet-1 kann ein Handshake mit dem ausgegebenen Paket simuliert werden. Die Datei packet-1 wird nun in einem Verzeichnis abgelegt, in unserem Beispiel das Verzeichnis in. Nun kann der eigentliche Fuzzing-Vorgang gestartet werden:

afl-fuzz -i in -o out -m -1 -t 5000 ./selftls 1 @@

Mit -i und -o werden das Ein- und das Ausgabeverzeichnis definiert, -m -1 schaltet das Speicherlimit ab und -t 5000 erhöht den Timeout, da ein TLS-Handshake vergleichsweise langsam abläuft. Beim Programmaufruf von selftls wird das @@ von American Fuzzy Lop durch die jeweilige Eingabedatei ersetzt.

Nach sechs Stunden ein Treffer

In unseren Tests lieferte American Fuzzy Lop circa sechs Stunden später das erste Ergebnis: Ein manueller Aufruf von selftls mit der Ausgabedatei ergibt einen Stack Trace und weitere Informationen von Address Sanitizer - ein Buffer Overflow, verursacht durch einen fehlerhaften Aufruf von memcpy() in der Funktion tls1_process-heartbeat(). Es ist der Heartbleed-Bug.

Einige erwähnenswerte Dinge sind beim Testen aufgefallen: Nach der Entdeckung von Heartbleed wurde mehrfach erwähnt, dass OpenSSL ein eigenes Speichermanagement nutzt, das angeblich dazu führte, dass Schutztechnologien ausgehebelt würden. Insbesondere eine E-Mail von OpenBSD-Entwickler Theo de Raadt wurde viel zitiert, in der dieser schrieb, dass OpenSSL "Umgebungstechnologien für Exploit-Schutzmechanismen" habe. Das OpenSSL-eigene Speichermanagement lässt sich beim Kompilieren durch den Parameter no-buf-freelist deaktivieren.

Zunächst sind wir davon ausgegangen, dass dies notwendig ist, damit Address Sanitizer korrekt funktioniert. Es stellte sich aber heraus, dass auch ohne diese Option Address Sanitizer den Bug erkennt. Zwar besitzt OpenSSL ein eigenes Speichermanagement, aber trotzdem wird offenbar für jeden zugewiesenen Puffer ein eigener Speicherbereich alloziert. Die Details des OpenSSL-Speichermanagements sind in einem Blogbeitrag von Chris Rohlf erläutert.

Randomisierung abzuschalten war nicht notwendig

American Fuzzy Lop wird beim Fuzzen des Test-Tools mit einer roten Zahl vor variablen Programmaufrufen warnen. Das bedeutet, dass das Programm sich manchmal bei identischen Eingabedaten unterschiedlich verhält. Der Grund dafür ist, dass der TLS-Handshake bei der Erstellung des sogenannten Master Secrets und in der RSA-Funktion Zufallszahlen nutzt. Um dies zu verhindern und den Handshake deterministisch ablaufen zu lassen, kann die Zufallszahlenfunktion von OpenSSL gepatcht werden und permanent lediglich den Wert Eins ausgeben. In unseren Tests benötigte American Fuzzy Lop etwa gleich lang zum Finden von Heartbleed, unabhängig davon, ob der Zufallszahlengenerator deaktiviert wurde oder nicht. Trotzdem erscheint es generell sinnvoll, zum Fuzzen von kryptographischen Anwendungen den Zufallszahlengenerator zu deaktivieren und keine echten Zufallszahlen ausgeben zu lassen.

Erwähnenswert ist außerdem, dass American Fuzzy Lop ein relativ neues Tool ist. Zum Zeitpunkt als Heartbleed gefunden wurde, war es zwar bereits verfügbar, allerdings kannte es kaum jemand. Die frühen Versionen waren zudem deutlich komplexer zu bedienen und hatten einige Fallstricke, insbesondere die Zusammenarbeit mit Address Sanitizer funktionierte nicht problemlos. Mit der damaligen Version hätte sich Heartbleed also nicht so einfach finden lassen.

Lernen für die Zukunft

Einen direkten Nutzen hat unser Experiment natürlich nicht, denn Heartbleed wurde längst gefunden und umfangreich analysiert, der OpenSSL-Code wurde gefixt und die meisten Systeme sind heute nicht mehr verwundbar. Allerdings lässt sich aus dem Experiment einiges lernen. Mit ähnlichen Strategien sollte es möglich sein, in Zukunft Heartbleed-ähnliche Bugs in anderer Software zu finden. Address Sanitizer und American Fuzzy Lop sind sehr mächtige Tools, die jeder Softwareentwickler kennen und nutzen sollte.

Eine ausführlichere englischsprachige Beschreibung des Fuzzing-Experiments hat der Autor in seinem Blog veröffentlicht. Außerdem hat er im vergangenen Jahr das Fuzzing Project mit dem Ziel gestartet, mehr Bugs in freier Software mittels Fuzzing zu finden. Dort gibt es auch ein Einsteiger-Tutorial.

Nachtrag vom 8. April 2015, 15:30 Uhr

Wir sind darauf hingewiesen worden, dass die Firma Codenomicon ebenfalls Heartbleed mit Hilfe eines Fuzzing-Tools gefunden hat. Das ist zwar korrekt, aber die dabei verwendete Strategie unterscheidet sich deutlich von der, die hier im Artikel beschrieben wurde. Zum Hintergrund: Heartbleed wurde ursprünglich von Neel Mehta von Google bei einer Analyse des OpenSSL-Codes entdeckt. Wenige Tage später wurde Heartbleed unabhängig davon von Entwicklern der Firma Codenomicon ebenfalls entdeckt. Die Details dazu hat Codenomicon-Mitarbeiter Antti Karjalainen in einem Vortrag erklärt, der auf Youtube zu finden ist;.

Codenomicon nutzte ein Fuzzing-Tool, das spezifisch auf TLS zugeschnitten war und spezielle Funktionen beinhaltete, die Anomalien entdeckten. Auch enthielt das Tool spezielle Mechanismen, um die Heartbeat-Erweiterung von TLS zu erkennen und zu prüfen. Derartige protokollbasierte Fuzzer können zwar Bugs wie Heartbleed finden, sie sind aber sehr aufwendig zu erstellen, da für jedes Format oder Protokoll, das gefuzzt werden soll, der Fuzzer angepasst werden muss.

Damit unterscheidet sich diese Vorgehensweise deutlich von der im Artikel vorgestellten Methode: Das Bemerkenswerte am Tool American Fuzzy Lop ist, dass es keinerlei Informationen über das verwendete Format oder Protokoll benötigt.

 Address Sanitizer und American Fuzzy Lop

eye home zur Startseite
Manga 27. Apr 2015

Ja stimmt... Du hast vollkommen recht... Es ist in der Größenordnung wie Native code...

olleIcke 16. Apr 2015

btw: bei xkcd wurde es auch schön anschaulich erklärt wie ich finde: xkcd.com/1354...

EvilSheep 09. Apr 2015

dem wunsch schliese ich mich an!

estev 09. Apr 2015

Made my day.

heftig 09. Apr 2015

Verdammt... zu spät :D



Anzeige

Stellenmarkt
  1. Columbus McKinnon Industrial Products GmbH, Wuppertal
  2. Alfred Kärcher GmbH & Co. KG, Winnenden bei Stuttgart
  3. Daimler AG, Stuttgart-Möhringen
  4. Statistisches Bundesamt, Wiesbaden


Anzeige
Spiele-Angebote
  1. (-70%) 5,99€
  2. 79,98€ + 5€ Rabatt (Vorbesteller-Preisgarantie)
  3. 19,99€

Folgen Sie uns
       


  1. Purism Librem 13 im Test

    Freiheit hat ihren Preis

  2. Andy Rubin

    Drastischer Preisnachlass beim Essential Phone

  3. Sexismus

    US-Spielforum Neogaf offenbar abgeschaltet

  4. Kiyo und Seiren X

    Razer bringt Ringlicht-Webcam für Streamer

  5. Pixel 2 XL

    Google untersucht Einbrennen des Displays

  6. Max-Planck-Gesellschaft

    Amazon eröffnet AI-Center mit 100 Jobs in Deutschland

  7. Windows 10

    Trueplay soll Cheating beim Spielen verhindern

  8. Foto-App

    Weboberfläche von Google Fotos hat Bilderlücken

  9. Fahrzeugsicherheit

    Wenn das Auto seinen Fahrer erpresst

  10. Mate 10 Pro im Test

    Starkes Smartphone mit noch unauffälliger KI



Haben wir etwas übersehen?

E-Mail an news@golem.de


Anzeige
Essential Phone im Test: Das essenzielle Android-Smartphone hat ein Problem
Essential Phone im Test
Das essenzielle Android-Smartphone hat ein Problem
  1. Teardown Das Essential Phone ist praktisch nicht zu reparieren
  2. Smartphone Essential Phone kommt mit zwei Monaten Verspätung
  3. Andy Rubin Essential gewinnt 300 Millionen US-Dollar Investorengelder

Pixel 2 und Pixel 2 XL im Test: Google fehlt der Mut
Pixel 2 und Pixel 2 XL im Test
Google fehlt der Mut
  1. Pixel Visual Core Googles eigener ISP macht HDR+ schneller
  2. Smartphones Googles Pixel 2 ist in Deutschland besonders teuer
  3. Pixel 2 und Pixel 2 XL im Hands on Googles neue Smartphone-Oberklasse überzeugt

Krack-Angriff: Kein Grund zur Panik
Krack-Angriff
Kein Grund zur Panik
  1. Neue WLAN-Treiber Intel muss WLAN und AMT-Management gegen Krack patchen
  2. Ubiquiti Amplifi und Unifi Erster Consumer-WLAN-Router wird gegen Krack gepatcht
  3. Krack WPA2 ist kaputt, aber nicht gebrochen

  1. Re: 2017 und 1080p30

    EdwardBlake | 11:52

  2. NeoGAF

    RonnyStiftel | 11:51

  3. Re: Lustige Szenarien. Lenkradsperre bei 250 KM/H

    chefin | 11:50

  4. Re: BMW

    Jodn | 11:50

  5. Re: Vorbei sind die Zeiten...

    david_rieger | 11:48


  1. 12:02

  2. 11:47

  3. 11:40

  4. 11:29

  5. 10:50

  6. 10:40

  7. 10:30

  8. 10:15


  1. Themen
  2. A
  3. B
  4. C
  5. D
  6. E
  7. F
  8. G
  9. H
  10. I
  11. J
  12. K
  13. L
  14. M
  15. N
  16. O
  17. P
  18. Q
  19. R
  20. S
  21. T
  22. U
  23. V
  24. W
  25. X
  26. Y
  27. Z
  28. #
 
    •  / 
    Zum Artikel