Aus Softwarefehlern lernen – Teil 6: Eine Zeile Code mit fatalen Auswirkungen

In der Softwareentwicklung gibt es Bereiche, in denen schon ein einziger Fehler katastrophale Folgen haben kann. Besonders anfällig sind dabei Kryptografiebibliotheken und Parser – also genau jene Bausteine, die Daten validieren, entschlüsseln oder die Integrität von Kommunikation sicherstellen.

In diesen Bereichen gilt: Ein vermeintlich kleiner Bug kann globale Auswirkungen haben. Zwei der bekanntesten Vorfälle der letzten Jahre illustrieren das eindrücklich, nämlich Heartbleed und Apples „goto fail“.

Muster 6: Kryptografie- und Parser-Fehler: Wenn eine einzige Codezeile die Sicherheit kippt

Heartbleed war ein Fehler in OpenSSL, einer der meistgenutzten Kryptografiebibliotheken der Welt. Der Bug betraf die Implementierung des TLS-Heartbeat-Mechanismus. Heartbeats sind kleine Nachrichten, mit denen Client und Server prüfen, ob die Verbindung noch lebt. Ein Client sendet (im Falle von TLS) dazu eine Nachricht, in der er unter anderem die Länge der eigenen Daten angibt. Der Server spiegelt diese Daten zurück.

Der fatale Fehler dabei war, dass die angegebene Länge nicht validiert wurde. Ein Angreifer konnte also behaupten, er sende zum Beispiel 64 KByte Daten, sendete tatsächlich aber nur 1 Byte. OpenSSL las daraufhin blind die fehlenden 63.999 Bytes aus seinem Speicher und schickte sie zurück. Diese Out-of-Bounds-Reads erlaubten es, mit ein bisschen Glück sensible Informationen wie Passwörter, Session Keys oder private Schlüssel auszulesen.

Die Tragweite war enorm. Millionen von Webservern waren betroffen, und weil TLS-Private-Keys kompromittiert waren, mussten die Betreiber zahllose Zertifikate austauschen. Der Bug bestand dabei über zwei Jahre in der OpenSSL-Codebasis, obwohl er nur wenige Zeilen lang war.

Fast zeitgleich machte Apple mit einem ebenfalls winzigen, aber folgenschweren Fehler namens goto fail Schlagzeilen. In der Implementierung der SSL-Zertifikatsprüfung in iOS und macOS fand sich eine verdoppelte Codezeile:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;

Die zweite goto fail-Zeile war dabei falsch eingerückt, sodass Reviewer den Fehler schlecht erkennen konnten. Das System führte die zweite Zeile nämlich immer aus, unabhängig vom Ergebnis der if-Anweisung. Das wiederum hatte zur Folge, dass das System einen Teil der sicherheitskritischen Zertifikatsprüfung übersprang. Dadurch konnte ein Angreifer einen Man-in-the-Middle-Angriff durchführen, weil macOS, iOS und andere Apple-Betriebssysteme gefälschte Zertifikate akzeptierten. Wie bei Heartbleed war der betroffene Code winzig, die Folgen jedoch massiv.

Was haben beide Fehler gemein? Sicherheitskritischer Code ist oft alt und wenig verändert: Entwicklerinnen und Entwickler fassen Parser, Krypto-Routinen oder Protokollimplementierungen selten an – und wenn, dann oft unter Zeitdruck.

1. Einzelne Zeilen können sicherheitsentscheidend sein: Die Logik ist komplex, Tests decken selten alle Pfade ab, und Compiler warnen nicht vor falscher Einrückung oder fehlender Längenvalidierung.
2. Fehler bleiben lange unentdeckt: Heartbleed war über zwei Jahre im Code. goto fail fiel erst auf, als unabhängige Forscher den Code analysierten.

Wer sicherheitskritische Software entwickelt oder integriert, sollte daher einige Prinzipien beherzigen:

1. Vier-Augen-Prinzip und Code-Reviews: Kein sicherheitsrelevanter Commit sollte von nur einer Person geschrieben und gemerged werden.
2. Fuzzing und Differential-Tests: Automatisierte Tests, die zufällige und manipulierte Eingaben erzeugen, decken viele Parser- und Memory-Bugs auf.
3. Reproduzierbare Builds und Dependency-Audits: Developer müssen sicherheitskritische Software in derselben Version reproduzierbar bauen und signieren. Änderungen in Libraries müssen sie aktiv verfolgen und bewerten.
4. Minimaler und isolierter Code: Krypto- und Parser-Funktionen sollten möglichst klein und möglichst isoliert sein, um die Angriffsfläche zu minimieren.
5. Proaktive Schlüssel- und Zertifikatsrotation: Selbst wenn ein Fehler wie Heartbleed auftritt, kann ein schneller Schlüsselaustausch die Folgen begrenzen.

Die beiden Fälle zeigen: Security-Bugs entstehen oft in den unscheinbarsten Codezeilen. Wer sie ignoriert, riskiert nicht nur Ausfälle, sondern auch Vertrauensverlust und juristische Folgen. Für Unternehmen ist daher klar: Sicherheitskritische Bereiche benötigen besondere Prozesse, zusätzliche Tests und regelmäßige Audits.

(who)