Fuzzing: Wie man Heartbleed hätte finden können

Vor einem Jahr machte der Heartbleed-Bug in OpenSSL Schlagzeilen - doch solche Bugs lassen sich mit Hilfe von Fuzzing-Technologien aufspüren. Wir haben das mit den Tools American Fuzzy Lop und Address Sanitizer nachvollzogen und den Heartbleed-Bug neu entdeckt.

Artikel von Hanno Böck veröffentlicht am 7. April 2015, 15:31 Uhr

American Fuzzy Lop kann Bugs wie Heartbleed finden. (Bild: Screenshot)

Vor einem Jahr, am siebten April 2014, veröffentlichten die Entwickler von OpenSSL Details zu einem Fehler in ihrer Software. Der Bug, der den Namen Heartbleed erhielt, führte zu einer intensiven Debatte über die Sicherheit wichtiger freier Softwareprojekte. Vielfach wurde dabei die Frage gestellt, warum dieser Fehler nicht früher gefunden wurde - über zwei Jahre befand sich Heartbleed im OpenSSL-Code.

Hätte Fuzzing Heartbleed gefunden?

Inhalt:

1. Fuzzing: Wie man Heartbleed hätte finden können
2. Address Sanitizer und American Fuzzy Lop
3. Fuzzing des TLS-Handshakes

Eine relativ simple Möglichkeit, Fehler in Software zu finden, ist das sogenannte Fuzzing. Die Idee dabei: Eine Software wird immer wieder mit Eingabedaten aufgerufen, die kleine Fehler enthalten. Stürzt das Programm ab, ist oft ein Fehler gefunden - in vielen Fällen deuten Abstürze auf fehlerhafte Speicherzugriffe hin, die zu Sicherheitslücken führen. Der IT-Sicherheitsspezialist David A. Wheeler hat sich nach Heartbleed ausführlich damit beschäftigt, ob und wie Fuzzing Heartbleed hätte finden können. Der Autor dieses Artikels konnte diese Frage nun in der Praxis beantworten.

Selbstverständlich ist es einfach, einen Fehler zu finden, wenn klar ist, wonach gesucht werden muss. Deshalb war bei diesem Experiment wichtig, dass keine spezifischen Informationen über Heartbleed genutzt werden sollten. So handelte es sich um einen Fehler in der TLS-Erweiterung Heartbeat - die kannte zum damaligen Zeitpunkt aber kaum jemand.

Fehlerhafter Lesezugriff im Speicher

Bei Heartbleed handelt es sich um einen Buffer Overflow beim Lesezugriff auf den Speicher. Solche Pufferüberläufe sind sehr häufig und auch schon seit Jahrzehnten bekannt. Als der Chaos Computer Club vor 30 Jahren das BTX-System der damaligen Deutschen Post hackte, nutzten die CCC-Mitglieder einen Bug, der Heartbleed erstaunlich ähnlich ist - zumindest wenn man ihrer Version der Geschichte glaubt.

Ein einfaches Beispiel für einen Buffer Overflow: Ein Programm nutzt einen Speicherbereich, der zehn Bytes lang ist. Versucht das Programm nun, aus diesem Speicherbereich 20 Bytes zu lesen, greift die Software auf den Speicher zu, der sich daneben befindet. Was dort gerade liegt, ist nicht genau vorhersehbar und hängt von vielen Details ab.

Um ein Programm erfolgreich fuzzen zu können, müssen die entsprechenden Fehler natürlich erkennbar sein, etwa durch einen Programmabsturz. Doch während schreibende Buffer Overflows meistens ein Programm zum Absturz bringen, läuft Software bei lesenden Buffer Overflows oft einfach weiter.

Es gibt eine Reihe von Tools, die eine bessere Erkennung von ungültigen Speicherzugriffen ermöglichen. Ein bekanntes Tool dieser Art ist Valgrind. Allerdings hat es einen Nachteil: Es ist extrem langsam, und die Ausführung eines Programms mit Hilfe von Valgrind dauert etwa zwanzigmal so lang wie sonst. Da man beim Fuzzing ein Programm millionenfach aufruft, ist Valgrind hier impraktikabel.