Heartbleed: Was man jetzt prüfen sollte

Keine Zeit? Hier die Kurzversion in 30 Sekunden.

• Seit dem 7. April ist Heartbleed (CVE-2014-0160) bekannt: Ein Fehler in der Heartbeat-Erweiterung von OpenSSL 1.0.1 bis 1.0.1f lässt Angreifer pro Anfrage bis zu 64 KB Serverspeicher auslesen.
• Betroffen sein können auch private Schlüssel, Passwörter und Session-Cookies, und es hinterlässt keine Spuren im Log.
• Reihenfolge: Version prüfen, OpenSSL auf 1.0.1g oder die Distributionsversion mit Fix bringen, Dienste neu starten, Zertifikate mit neuem Schlüssel ersetzen, Passwörter und Sitzungen erneuern.
• Java-Anwendungen mit JSSE sind selbst nicht betroffen, wohl aber alles, was davorsteht: Apache, nginx, Load-Balancer.

Die vergangene Woche war keine gute für alle, die Server betreiben. Am 7. April wurde der Fehler in OpenSSL öffentlich, der inzwischen Heartbleed heißt, und seitdem gibt es kaum ein anderes Thema. Ich schreibe hier nicht, was ohnehin überall steht, sondern eine Liste, die man abarbeiten kann. Denn das Schlimme an dem Fehler ist nicht nur seine Wirkung, sondern dass man sich mit dem Patch allein nicht zufriedengeben darf.

Was genau passiert

TLS kennt eine Erweiterung namens Heartbeat. Eine Seite schickt eine kleine Nutzlast und eine Längenangabe, die Gegenseite soll genau diese Nutzlast zurückschicken, damit die Verbindung als lebendig gilt. In den betroffenen OpenSSL-Versionen wird die angegebene Länge nicht gegen die tatsächlich gesendete Menge geprüft. Wer eine winzige Nutzlast schickt, aber eine große Länge behauptet, bekommt zusätzlich ein Stück Speicher aus dem Prozess zurück, bis zu 64 KB pro Anfrage. Das lässt sich beliebig oft wiederholen.

Was dort im Speicher liegt, hängt vom Zufall ab: Anfragen anderer Benutzer, Passwörter, Session-Cookies und im ungünstigsten Fall der private Schlüssel des Servers. Ob Letzteres praktisch gelingt, wurde in den ersten Tagen noch diskutiert, ausschließen darf man es nicht. Der Zugriff passiert zudem innerhalb des TLS-Protokolls und taucht in keinem Zugriffslog auf. Man erfährt also nie, ob jemand da war, und muss davon ausgehen, dass es möglich war.

Betroffen sind OpenSSL 1.0.1 bis 1.0.1f. Die Zweige 1.0.0 und 0.9.8 haben die Heartbeat-Funktion nicht und sind nicht verwundbar. Der Fehler ist in 1.0.1g behoben.

Die Checkliste

1. Version feststellen. openssl version -a zeigt Version und Build-Datum. Aber Vorsicht: Viele Distributionen übernehmen nur den Fix und behalten die alte Versionsnummer. Eine Anzeige von 1.0.1e heißt deshalb nicht automatisch, dass man verwundbar ist. Verlässlicher ist der Blick in die Sicherheitshinweise der Distribution oder ins Changelog des Pakets. Zusätzlich muss man wissen, ob andere Programme eine eigene, mitgelieferte OpenSSL-Bibliothek enthalten.
2. Patchen. Paket aktualisieren oder 1.0.1g einspielen. Wer sofort nichts aktualisieren kann, kann OpenSSL notfalls mit der Option -DOPENSSL_NO_HEARTBEATS neu kompilieren.
3. Dienste neu starten. Das wird gern vergessen. Eine aktualisierte Bibliothek auf der Platte nützt nichts, solange der laufende Prozess die alte im Speicher hält. Alles neu starten, was sie nutzt: Webserver, Mailserver, VPN, Datenbanken mit TLS.
4. Zertifikate neu ausstellen. Mit neuem Schlüsselpaar, nicht nur mit neuem Zertifikat zum alten Schlüssel. Wer den privaten Schlüssel nicht sicher als unberührt betrachten kann, sollte das alte Zertifikat bei der Zertifizierungsstelle widerrufen.
5. Passwörter und Sitzungen. Bestehende Sessions beenden, Passwörter ändern lassen, API-Schlüssel und Tokens erneuern. Das aber erst, nachdem der Dienst gepatcht ist, sonst liest jemand das neue Passwort beim nächsten Login womöglich gleich wieder mit.

Mit dem Widerruf ist es übrigens so eine Sache. Ob Browser gesperrte Zertifikate zuverlässig prüfen, ist alles andere als sicher. Ich würde mich nicht darauf verlassen, dass ein widerrufenes Zertifikat Angreifer wirklich aussperrt. Den Austausch des Schlüssels sollte man trotzdem tun, er begrenzt zumindest den Schaden.

Was man sonst noch beachten sollte

Ein Test von außen ersetzt die Prüfung der Version nicht, ist aber nützlich. Es gibt inzwischen mehrere Online-Dienste, die einen Server auf die Schwachstelle prüfen. Ein negatives Ergebnis beruhigt allerdings nur für den getesteten Port. Mailserver mit STARTTLS, ein VPN-Dienst oder eine Datenbank mit TLS-Anbindung sind damit nicht abgedeckt. Die Liste der Dienste, die OpenSSL einsetzen, ist meist länger, als man beim ersten Nachdenken vermutet.

Mir hilft es, die Prozesse zu betrachten, die die Bibliothek tatsächlich geladen haben. Unter Linux zeigt ein Blick auf die geöffneten Dateien, welche Programme noch die alte libssl im Speicher halten. Die sollten nach dem Update alle einmal neu gestartet worden sein, und im Zweifel ist ein Neustart des ganzen Rechners die ehrlichste Lösung.

Ein letzter Punkt, der gern übersehen wird: Auch Geräte und Software von Herstellern bringen OpenSSL mit, etwa Router, Appliances oder Verwaltungsoberflächen. Hier hängt es vom Hersteller ab, wann ein Update kommt. Solange es keins gibt, hilft nur, den Zugang einzuschränken und im Zweifel auszuschalten.

Java, PHP, C++

Für Java-Anwendungen gibt es eine gute Nachricht: Die JSSE-Implementierung hat mit OpenSSL nichts zu tun, ein reiner Java-Server mit eigenem TLS ist nicht betroffen. Das gilt aber nur für diesen Fall. Steht ein Apache, ein nginx oder ein Load-Balancer als TLS-Terminierung davor, steht die Anwendung hinter einer verwundbaren Komponente. Und wer Tomcat mit der nativen APR-Bibliothek betreibt, nutzt dort ebenfalls OpenSSL.

Auch Clients können betroffen sein. Die Schwachstelle funktioniert in beide Richtungen, ein präparierter Server könnte Speicher eines Clients auslesen, der eine verwundbare Bibliothek benutzt. Für PHP und für C++-Programme, die OpenSSL linken, lohnt sich deshalb der Blick, gegen welche Bibliothek sie laufen. Beides gehört zu den Dingen, die man nur findet, wenn man sie sucht, und die in keiner Inventarliste stehen.

Was ich daraus mitnehme

Im vergangenen Jahr habe ich nach den PRISM-Enthüllungen darüber geschrieben, wie man in eigenen Anwendungen sauber verschlüsselt. Heartbleed erinnert daran, dass alle Sorgfalt nichts nützt, wenn die darunterliegende Bibliothek einen simplen Prüffehler enthält. TLS ist nur so gut wie seine Implementierung. Das Protokoll war nie das Problem, es war eine fehlende Längenprüfung in einer Erweiterung, die kaum jemand brauchte.

Daraus lassen sich zwei Dinge ableiten. Erstens will man wissen, welche Komponenten im eigenen Betrieb überhaupt Kryptografie bereitstellen, und das schnell herausfinden können. Zweitens sollte das Austauschen von Zertifikaten und Schlüsseln eine eingeübte Routine sein und kein Ausnahmefall. Wer es diese Woche zum ersten Mal gemacht hat, wird dankbar sein, das nächste Mal nicht wieder improvisieren zu müssen.

Und auch das: Es lohnt sich, Open-Source-Komponenten, auf denen halbe Infrastrukturen laufen, nicht für selbstverständlich zu halten. Solche Bibliotheken werden von wenigen Leuten gepflegt, und von außen sieht sie fast niemand genau an.

Beitragsbild: eigene Collage mit Logos von Wikimedia Commons (Heartbleed-Logo: Leena Kurjenniska / Codenomicon, CC0 1.0); die Marken gehören ihren Inhabern.