Heartbleed und die Folgen

Da gibt es also eine Schwachstelle in einer Programmerweiterung von SSLeay (Heute Open SSL).
Nicht dass das nicht zu erwarten gewesen wäre, aber die Art des "Programmierfehlers" und seine über 2 Jahre Ausnutzbarkeit in einer der wichtigsten Security-Bibliotheken hinterlässt ein ungutes Gefühl.

Kurz noch einmal zu den Fakten:

Vor etwas über 2 Jahre schlägt ein deutscher Student eine Erweiterung für OpenSSL vor die eine Heartbeat Funktion per SSL einführt.
Davon abgesehen, dass es ohnehin fraglich ist ob man so eine Funktion braucht, ist es noch fraglicher ob sie dann so seltsam programmiert werden muss.

Beim Hertbeat fordert sendet ein Partner an den Anderen einen Hearbeat Request mit einem zufälligen Fragment aus dem Speicher als "Token".
Das alleine ist schon irgendwie seltsam. Noch seltsamer ist allerdings, dass der Absender des Requests dem Empfänger angibt, wie groß das Speicherfragment ist, dass er gesendet hat.
Sendet der Absender nur wenige Byte und behauptet es wären 64KByte gewesen, dann sendet der Empfänger eben 64 Kbyte, die er ausgerechnet aus dem Speicher des SSL Prozesses nimmt.
Nun könnte man sagen, 64kByte Speicherinhalt? Was kann man als Angreifer damit schon anfangen?
Eine ganze Menge! Denn irgendwo im Speicher z.B. eines Webservers befinden sich bei aktivem SSL die Secret Keys, die User Credentials, die Sitzungsschlüssel, etc. Natürlich letzlich im Klartext.

(Zum nachlesen bei Heise:)

http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html

Das eine solche Attacke auch praktisch durchführbar ist zeigt:

http://www.heise.de/ix/meldung/Heartbleed-Worstcase-Server-Schluessel-kann-ausgelesen-werden-2169180.html

Wie sollte es ohne externes Krypto Device auch anders gehen? Ok, man könnte einen Speicherbereich verschlüsseln, aber auch dieser Schlüssel müsste dann ja wieder entschlüsselt werden und so weiter…..
Irgendwie muss der Key ja mal im „Klartext“ im Speicher sein, sonst könnte er ja nicht genutzt werden.

Was das bedeutet, kann sich eigentlich jeder selbst ausmalen....
Nein? OK! Dann mal meine Auflistung der empfohlenen Maßnahmen:

  • Als erstes natürlich alle Bugfixes einspielen für die betroffenen Systeme. (und das sind eine ganze Menge)
  • Dann alle SSL Zertifikate neu ausstellen (oder ausstellen lassen)
  • Alle Nutzer auffordern, neue Passwörter zu wählen.

Nun bin ich sicher besonders misstrauisch und paranoid, aber wer jetzt einfach den Kopf in den Sand steckt und das übliche „Ach es wird schon nichts passiert sein“ trällert, ist m.E. eher naiv.

Fazit:

  • Vielleicht sollte man OpenSource nicht per se vertrauen. Die reine Möglichkeit zum CodeReview bedeutet nicht, dass es auch jemand durchgeführt hat.
  • Neuerungen an so wichtigen Bibliotheken sollten vielleicht vorab auf ihre Sinnhaftigkeit und Korrektheit geprüft werden
  • Wie viele "Fehler" stecken wohl in ClosedSource, wo die Fehler nicht einmal auffallen können, da schlicht die einfache Möglichkeit zum Review fehlt?

 Man mag es sich gar nicht weiter ausmalen....