Heartbleed – Problem oder Chance?

Der Heartbleed-Angriff, der letzte Woche veröffentlicht wurde, hat die Grundfeste der IT-Security erschüttert. Alle möglichen Technologiemedien haben sich auf das Thema gestürzt und auch in der Community ist neue Bewegung in das Thema Infrastrukturgrundlagen gekommen. Doch was ist überhaupt los?

Bei OpenSSL handelt es sich um eine OpenSource-Bibliothek, die grundlegende Funktionen für die verschlüsselte Kommunikation im Internet bereitstellt. Diese Bibliothek wird von vielen Anwendungen verwendet, die verschlüsselt über das Internet kommunizieren müssen. Genau in dieser Bibliothek wurde ein schwerwiegender Fehler gefunden.

Bei XKCD ist dazu ein einfach zu verstehender Comic erschienen. Im Grunde passiert folgendes: Damit ein normaler Nutzer herausfinden kann, ob die Verbindung zu einem Server noch besteht, kann man ihm einfach eine beliebige Nachricht schicken. Erhält man die gleiche Nachricht zurück, ist der Server offenbar noch erreichbar.

In der bisherigen Implementierung war jedoch eine riesige Lücke. In der Anfrage des Nutzers gibt der Nutzer selbst an, wie lang die Daten sind, die zurückgeschickt werden sollen. Der Server glaubte dieser Angabe und schickte genau so viele Daten aus seinem Speicher zurück - auch dann, wenn die Daten, die der Nutzer wirklich geschickt hat, viel kürzer waren. Das führte dazu, dass Daten an den Nutzer geschickt wurden, die ihn gar nicht betreffen, wie z.B. Zugangsdaten fremder Nutzer.

Seit dem Bekanntwerden haben alle möglichen Medien über das Thema berichtet - teils werden Horrorszenarien verbreitet. Doch auch in Kreisen, die sich mit der Materie auskennen, ist man beunruhigt. Wenn solch ein schlampiger Fehler in einer der wichtigsten Bibliotheken des WWW seit 2 Jahren unentdeckt vorhanden war, was mag dann noch alles im OpenSSL-Quelltext auf uns warten?

Inzwischen werden Rufe danach laut, dass man OpenSSL einmal vollständig auditieren sollte - sprich: dass jemand den gesamten Quelltext auf mögliche Fehler hin überprüfen sollte.

In meinen Augen ist das ein aussichtsloses Unterfangen. Wer sich schon einmal die Mühe gemacht hat, sich allein in die OpenSSL-API einzulesen, weiß, was ich meine. Die gesamte Bibliothek ist im Grunde ein riesiger, komplexer Bloat, mit zig internen Abhängigkeiten, später hinzugefügten Laschen und Ösen und ist nur schwer zu durchdringen.

Mitunter wird empfohlen, nicht direkt OpenSSL einzusetzen, sondern einen Wrapper zu nutzen, der die Komplexität verschleiert. In meinen Augen ist das ein Armutszeugnis. Es gibt Ecken, in denen das ganze besser funktioniert - zum Beispiel bei den Ciphersuits. Anstatt sich selbst zu überlegen, was funktionieren könnte und was wohl eine starke Kombination ist, kann man sich einfach eine sortierte Liste der möglichen Kombinationen ausgeben lassen und diese nutzen.

Meiner Meinung nach müsste OpenSSL generell diese Möglichkeit bieten. Es sollte einfach sein, mit wenig Aufwand einen sicheren Kanal zu erhalten. Man muss es hinkriegen, dass es schwieriger ist, es falsch zu machen, als es richtig zu machen. Das setzt jedoch voraus, dass man einige Teile grundlegend neu schreibt. Auch der Einsatz modernerer, sicherer Programmiersprachen wäre ein Schritt in die richtige Richtung.

Die Frage, wer nun Schuld an der Misere hat, stellt sich in meinen Augen hingegen nicht. Ja, der Entwickler, der den Code eingestellt hat, arbeitet inzwischen bei einer Telekom-Tochter. Ja, der Reviewer, der den Code akzeptiert hat, hätte den Fehler sehen müssen. Jedoch bleibt OpenSSL primär eines: eine frei verfügbare Implementierung, mit offen zugänglichem Quelltext, der jedem die Möglichkeit gibt, Fehler zu finden. Wir sollten zusehen, dass die Komponenten, die für unseren Alltag so wichtig sind, mehr engagierte Entwickler zur Verfügung haben.

Was nun zu tun bleibt:

  • Jeder, der eine verwundbare OpenSSL-Version einsetzt, muss diese patchen.
  • Jeder, der eine verwundbare OpenSSL-Version patchen musste, muss neue Schlüsselpaare erzeugen.
  • Jeder, der neue Schlüsselpaare erzeugen musste, muss sich für diese neue Zertifikate ausstellen lassen.
  • Jeder, der sich neue Zertifikate ausstellen lassen musste, muss seine alten Zertifikate revoken lassen.
  • Jeder, der seine alten Zertifikate revoken lassen musste, muss seine Nutzer informieren und zur Änderung ihrer Passwörter aufrufen.
  • Jeder, der seine Nutzer zur Änderung ihrer Passwörter aufrufen musste, muss die bereits laufenden Nutzersessions beenden, damit früher abgefangene Nutzersessions nicht weiter ausgenutzt werden können.

Es bringt derzeit nichts, vorsorglich seine Passwörter zu ändern. Solange die Server noch verwundbar sind, können auch neu gesetzte Passwörter wieder gestohlen werden. Langfristig ist es zudem angebracht, für jeden Dienst ein eigenes Passwort zu verwenden. So sind Dienste, die nicht von der OpenSSL-Lücke betroffen sind, gar nicht erst in Gefahr. Helfen können dabei Lösungen wie z.B. calc.pw. 😉

Herzblutende Grüße, Kenny

P.S.: Für meine Server habe ich bereits alles erledigt. Gepatcht, Schlüssel erzeugt, neue Zertifikate erstellt, alte Zertifikate revoked und die Nutzer mit Logins informiert und zum Passwortwechsel aufgerufen.

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.