OpenSSL: Wichtige Fragen und Antworten zu Heartbleed

Der Heartbleed-Bug in OpenSSL dürfte wohl als eine der gravierendsten Sicherheitslücken aller Zeiten in die Geschichte eingehen. Wir haben die wichtigsten Infos zusammengefasst.

Artikel von Hanno Böck veröffentlicht am 9. April 2014, 16:30 Uhr

(Bild: Screenshot Golem.de)

Der Heartbleed-Bug ist eine Sicherheitslücke mit kaum zu überschauenden Auswirkungen. Wir haben versucht, einige der wichtigsten Fragen zu beantworten.

Welche OpenSSL-Versionen sind betroffen?

Der Bug befindet sich in OpenSSL im Code für die Heartbeat-Erweiterung von TLS. Dieser wurde mit der Version 1.0.1 eingeführt, welche am 14. März 2012 veröffentlicht wurde. Der Bug bestand bis zur Version 1.0.1f. Auch Beta-Versionen von OpenSSL 1.0.1 sind betroffen, die Beta 1 wurde am 3. Januar 2012 veröffentlicht. In das Code-Repository von OpenSSL wurde die Heartbeat-Erweiterung am 1. Januar 2012 eingepflegt.

Jedoch kann man OpenSSL auch ohne Heartbeat-Support kompilieren. Es ist also selbst bei einer verwundbaren Version nicht gesichert, ob sie von Heartbleed betroffen ist.

Sind Server und Clients betroffen?

Ja, allerdings in unterschiedlichem Ausmaß. Ein Angriff auf einen Server ist trivial und lässt sich durch einen simplen Verbindungsaufbau mit Hilfe eines manipulierten Datenpakets durchführen. Bei einem Client muss ein Angreifer entweder eine Man-in-the-Middle-Attacke durchführen oder das Opfer dazu bringen, sich mit einem manipulierten Server zu verbinden.

Welche Programme benutzen OpenSSL?

Extrem viele. Auf Serverseite ist OpenSSL in der freien Softwarewelt quasi Standard. Die Webserver Apache und nginx, gängige Mailserver wie Postfix oder Sendmail, die meisten FTP-Server, Jabber-Server und viele mehr verwenden die Kryptobibliothek.

Auf Clientseite sind es etwas weniger. Die gängigen Browser benutzen überwiegend andere Bibliotheken. Firefox und Chrome nutzen für SSL-Verbindungen NSS, der Internet Explorer setzt auf das von Windows mitgelieferte SChannel. Gleiches gilt für die viel verwendeten Mailprogramme Thunderbird und Outlook Express. Dennoch gibt es unzählige andere Clientprogramme, die OpenSSL einsetzen, angefangen von trivialen Tools wie Wget oder Curl bis hin zu manchen Browsern und Mailprogrammen.

Die Lizenz von OpenSSL ist relativ liberal. Sie erlaubt die Verwendung des Codes auch in kommerziellen, nicht quelloffenen Programmen. Insofern ist kaum umfassend überprüfbar, wer alles OpenSSL-Code in seine Programme einbaut.

Ist SSH betroffen?

Nein. OpenSSH nutzt zwar die OpenSSL-Bibliothek für die Nutzung von kryptographischen Algorithmen, allerdings ist die Heartbeat-Erweiterung eine reine TLS-Angelegenheit. Programme, die zwar vom Kryptographiecode von OpenSSL Gebrauch machen, aber damit andere Protokolle wie SSH realisieren, sind somit nicht betroffen.

Was gilt jeweils für Windows, Linux, Mac OS X und andere Betriebssysteme?

Windows selbst besitzt eine eigene SSL-Bibliothek namens SChannel, die nichts mit OpenSSL zu tun hat. Mac-OS-X-Nutzer haben ebenfalls Glück: Apple nutzt eine ältere Version von OpenSSL (0.9.8), die nicht von Heartbleed betroffen ist.

Unter nahezu allen Linux-Distributionen gehört OpenSSL zur Standardausstattung, gleiches gilt auch für alle BSD-Systeme. Alle wichtigen Distributionen haben Updates bereitgestellt, die Anwender, falls nicht schon geschehen, umgehend installieren sollten.

Für alle Betriebssysteme gilt unabhängig davon: Es ist immer möglich, dass Programme ihre eigene OpenSSL-Version mitliefern. Auf Webservern betrifft das beispielsweise das SPDY-Modul von Google.

Was ist mit Android?

In der bei Android mitgelieferten OpenSSL-Version wurde Heartbeat am 25. Juni 2012 deaktiviert, also wenige Monate nach der Veröffentlichung des problematischen Codes. Vermutlich sind damit nur wenige Android-Telefone und Versionen betroffen. Die einzige Version von Android, die damit betroffen ist, ist laut Googles Sicherheitsteam die Version 4.1.1.

Unabhängig davon ist es natürlich möglich, dass einzelne Apps OpenSSL nutzen und selbst den verwundbaren Code mitliefern. Das kann nur im Einzelnen für jede App überprüft werden.

Was ist mit iPhones und iPads?

Das mobile System iOS von Apple liefert OpenSSL nicht mit. Trotzdem gilt dasselbe wie bei Android: Einzelne Apps können den Code von OpenSSL nutzen und selbst mitliefern.

Was müssen Server-Administratoren beachten?

Nach einem Update müssen alle Services, die OpenSSL benutzen, neu gestartet werden. Das gilt beispielsweise für Webserver oder Mailserver. Andernfalls haben diese die alte OpenSSL-Version noch im Speicher. Es gibt ein für Administratoren sehr nützliches Skript namens lib_users, welches unter Linux-Systemen herausfindet, welche laufenden Programme Bibliotheken verwenden, die nicht mehr installiert sind.

Was genau kann ein Angreifer mit Heartbleed auslesen und sind wirklich private Keys bedroht?

Heartbleed ermöglicht das Auslesen eines 64 Kilobyte großen Speicherblocks der Applikation, die OpenSSL benutzt. Was sich in diesem Speicher befindet, ist nicht vorhersehbar. Das hängt von vielen Faktoren ab, etwa davon, wie das Betriebssystem Daten im Speicher ablegt und was die Anwendung dort alles in welcher Reihenfolge speichert. Auf Twitter gab es zahlreiche Berichte, wonach bei Versuchen TLS-Sessioncookies und teilweise auch Benutzernamen und Passwörter von anderen Nutzern ausgelesen wurden.

Unklar ist, wie häufig wirklich der Fall auftritt, dass sich dort der private Key eines Servers verbirgt. Auf einer von der Firma Codenomicon aufgesetzten Webseite zum Heartbleed-Bug wird behauptet, dass die Mitarbeiter es schafften, von ihren eigenen Servern private Keys auszulesen. Auf Twitter berichten Nutzer, dass es in Tests gelang, unter FreeBSD und unter Gentoo private Keys von Apache auszulesen - allerdings nur direkt nach dem Neustart des Webservers. Uns ist aktuell nicht bekannt, ob irgendwo private Keys von öffentlich zugänglichen Webseiten veröffentlicht wurden.