Original-URL des Artikels: https://www.golem.de/news/openssl-wichtige-fragen-und-antworten-zu-heartbleed-1404-105740.html    Veröffentlicht: 09.04.2014 16:30    Kurz-URL: https://glm.io/105740

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.

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.



Gefährdete Zertifikate und Passwörter



Webseitenbetreiber sollen Zertifikate austauschen. Was muss man dabei beachten und wie kooperativ verhalten sich die Zertifizierungsstellen?

Wichtig ist, dass man nicht einfach ein bestehendes Zertifikat erneuert, sondern ein komplett neues Zertifikat mit einem neuen privaten Schlüssel erstellt. Wichtig ist auch zu überprüfen, dass das alte Zertifikat von der entsprechenden Zertifizierungsstelle wirklich zurückgezogen wurde. Das kann man beispielsweise mit dem OCSP-Tool von OpenSSL testen, die Bedienung ist allerdings nicht gerade nutzerfreundlich.

Die Zertifizierungsstellen reagieren offenbar sehr unterschiedlich. Einige Nutzer zeigten sich verärgert über StartSSL. Die Zertifizierungsstelle ist sehr beliebt, weil man dort einfache Zertifikate kostenlos erhält. Doch um ein solches Zertifikat neu zu erstellen, muss man zunächst das alte zurückziehen lassen. Und das kostet pro Zertifikat 24,90 US-Dollar. Zahlenden Kunden erlässt StartSSL offenbar die Kosten. Der Autor dieses Artikels konnte ein Wildcard-Zertifikat kostenlos zurückziehen.

Laut einem Bericht von Heise werden von GlobalSign Zertifikate kostenlos ausgetauscht, Kunden müssen sich dafür im Kundencenter anmelden. Ein von Comodo ausgestelltes Zertifikat konnte vom Autor dieses Artikels ebenfalls kostenlos ersetzt werden. Die Pressestelle der Symantec-Tochter Verisign, der weltweit größten Zertifizierungsstelle, hat uns mitgeteilt, dass ein Austausch von Zertifikaten dort ebenfallskostenlos möglich ist.

Müssen auch Passwörter ersetzt werden?

Es gibt zahlreiche Berichte, wonach mit Hilfe des Heartbleed-Bugs Passwörter von Web-Services ausgelesen werden konnten. Offenbar war hier besonders Yahoo anfällig und hat relativ lange zur Aktualisierung seiner Server gebraucht. Insofern lautet die Antwort: Im Zweifelsfall ja.

Was ist diese Heartbeat-Erweiterung eigentlich?

Heartbeat ist eine Erweiterung für TLS und wurde im IETF-Standard RFC 6520 spezifiziert. Sie ermöglicht es, bei langlebigen TLS-Verbindungen regelmäßig ein sogenanntes Keep-Alive-Signal zu senden, um einen Abbruch der Verbindung zu verhindern. Gängige Anwendungen wie HTTPS-Server benötigen so etwas eigentlich nicht. Aber der Code ist standardmäßig in OpenSSL aktiviert.

Felix von Leitner vom Chaos Computer Club ist der Meinung, dass das Heartbeat-Protokoll unnötig komplex ist und solche Fehler geradezu provoziert.

Wieso passiert so etwas überhaupt und ist C daran Schuld?

Bei Heartbleed wird aufgrund eines Fehlers zu viel Speicher ausgelesen. Eine detaillierte Analyse des C-Codes mit dem Heartbleed-Bug gibt es im Blog des Programmierers Sean Cassidy. Das Problem: Programme, die in der Programmiersprache C geschrieben sind, haben eine relativ simple Speicherverwaltung. Wenn ein Programm Variablen nutzt oder Speicherblöcke via malloc anfordert, werden diese einfach hintereinander im Speicher abgelegt. Wenn jetzt das Programm einen Speicherblock ausliest und dabei zu viele Daten einliest, wird einfach weitergelesen - was auch immer da im Speicher steht.

Es gilt aus diesem Grund als extrem schwierig, in C wirklich sicheren Code zu schreiben. Das ändert aber nichts daran, dass C nach wie vor die mit Abstand wichtigste Programmiersprache überhaupt ist. Praktisch alle Betriebssysteme und wichtigen Basisbibliotheken sind in C geschrieben.

Es gibt eine LLVM-Erweiterung namens Softbound CETS, die versucht, entsprechende Sicherheitslücken in C zu verhindern, indem das Auslesen von Speicherbereichen auf den ihnen zugewiesenen Speicherbereich beschränkt wird. Auf dem 30C3 gab es dazu einen Vortrag von Andreas Bogk vom Chaos Computer Club.

Das OpenBSD-Betriebssystem hat bereits in Ansätzen derartige Schutzmaßnahmen in den Funktionen malloc und mmap. Diese hätten bei Heartbleed greifen müssen, allerdings - darauf weist OpenBSD-Entwickler Theo de Raadt in einer Mail hin - wurden diese von OpenSSL umgangen. OpenSSL nutzt nicht die normalen Speicherverwaltungs-Aufrufe des Betriebssystems, sondern ersetzt sie durch eine eigene Speicherverwaltung.

Wie läuft die Entwicklung von OpenSSL ab?

Obwohl OpenSSL von unzähligen Programmen und großen Unternehmen genutzt wird, hat es nur ein relativ kleines Entwicklerteam. Viele fordern daher, dass das Projekt mehr Unterstützung erhält. So schreibt beispielsweise der Kryptograph Matthew Green: "Während einige der großen Firmen ihre Server patchen, können sie vielleicht überlegen, ob sie den OpenSSL-Entwicklern etwas Bezahlung zukommen lassen, damit diese ihren Job besser erledigen können."

Eine große Firma, die OpenSSL bereits unterstützt, ist Google. Der Suchmaschinenkonzern plant, seinen Browser Chrome von NSS auf OpenSSL umzustellen. Der Google-Angestellte Adam Langley ist bereits jetzt ein aktiver Entwickler bei OpenSSL.

Wie lief die Entdeckung und Veröffentlichung von Heartbleed ab?

Heartbleed wurde unabhängig von Mitarbeitern der finnischen Firma Codenomicon und von Neel Metha vom Google-Sicherheitsteam entdeckt. Beide teilten ihre Ergebnisse den OpenSSL-Entwicklern mit.

Die Veröffentlichung lief offenbar etwas chaotisch ab. Eigentlich war noch eine zweitägige Wartephase zwischen den Beteiligten vereinbart worden, aber irrtümlich wurden bereits Informationen über den Bug im Netz veröffentlicht. Wer dafür verantwortlich war, konnten wir nicht nachvollziehen. Auf der Mailingliste oss-security gibt es zum Veröffentlichungsablauf einen längeren Thread.

Die großen Linux-Distributionen hatten aufgrund des chaotischen Ablaufs vorab von der Veröffentlichung nichts gewusst und konnten somit erst mit einigen Stunden Verspätung reagieren. Offenbar wusste die Firma Cloudflare bereits eine Woche vorher Bescheid und hatte ihre Server bereits abgesichert. Cloudflare ist ein großer Anbieter von Content-Delivery-Netzwerken.

Was bedeutet eigentlich CVE-2014-0160?

Die US-Organisation MITRE vergibt für Sicherheitslücken üblicherweise eine sogenannte CVE-ID, mit der diese eindeutig identifiziert und referenziert werden können. Sie enthalten immer eine Jahreszahl und eine dem jeweiligen Problem zugewiesene Nummer. MITRE ist eine Forschungsorganisation und agiert hauptsächlich im Auftrag der US-Regierung, CVE steht für Common Vulnerabilities and Exposures. Der Heartbleed-Bug hat die ID CVE-2014-0160 erhalten.

Wie kann man testen, ob ein Service oder eine Software von Heartbleed betroffen ist?

Es gibt zahlreiche Webseiten, die das Testen von Servern ermöglichen, teilweise nur für den HTTPS-Port, teilweise auch für andere Services. Auch der beliebte SSL-Test der Firma Qualys prüft inzwischen auf Heartbleed.

Daneben sind auf Github zahlreiche Tests veröffentlicht worden, häufig genutzt ist etwa dieses Python-Testscript. Ein anderes auf Github veröffentlichtes Script kann auch Services mit STARTTLS-Erweiterung prüfen. Auch für Client-Anwendungen gibt es inzwischen Tests in Python und in Ruby.

Nachtrag vom 10. April 2014, 10:00 Uhr

Wir haben im Abschnitt "Was ist mit Android?" eine Information hinzugefügt (Version 4.1.1 betroffen) und den letzten Absatz zu Tests für Client-Applikationen ergänzt.

Nachtrag vom 10. April 2014, 11:19 Uhr

Von Verisign wurde uns mitgeteilt, dass dort ein kostenloser Tausch der Zertifikate ebenfalls möglich ist, wir haben dies im Artikel ergänzt.

Nachtrag vom 10. April 2014, 12:02 Uhr

Wir hatten ursprünglich fälschlicherweise im Abschnitt "Welche Programme benutzen OpenSSL?" geschrieben, dass Opera betroffen sei. Opera nutzt zwar OpenSSL, deaktiviert jedoch die Heartbeat-Funktionalität. Der Text wurde entsprechend angepasst.  (hab)


Verwandte Artikel:
JoltandBleed: Oracle veröffentlicht Notfallpatch für Universitäts-Software   
(20.11.2017, https://glm.io/131238 )
Trustico/Digicert: Chaos um 23.000 Zertifikate und private Schlüssel   
(01.03.2018, https://glm.io/133077 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )
Cisco: Kritische Lücke im VPN ermöglicht DoS-Angriffe auf Switches   
(30.01.2018, https://glm.io/132470 )
Sicherheitslücke: Keys auslesen mit OpenSSL   
(08.04.2014, https://glm.io/105685 )

© 1997–2020 Golem.de, https://www.golem.de/