Der Heartbleed-Bug ist ein schwerwiegender Programmfehler in älteren Versionen der Open-Source-Bibliothek OpenSSL, durch den über verschlüsselte TLS-Verbindungen private Daten von Clients und Servern ausgelesen werden können. Der Fehler betrifft die OpenSSL-Versionen 1.0.1 bis 1.0.1f und wurde mit Version 1.0.1g am 7. April 2014 behoben. Ein großer Teil der Online-Dienste, darunter auch namhafte Websites wie auch VoIP-Telefone, Router und Netzwerkdrucker waren dadurch für Angriffe anfällig.
Der Fehler befindet sich in der OpenSSL-Implementierung der Heartbeat-Erweiterung für die Verschlüsselungsprotokolle TLS und DTLS. Die Heartbeat-Erweiterung sieht vor, dass ein Kommunikationsteilnehmer eine bis zu 16 kByte große Menge an beliebigen Daten (Payload und Padding) an die Gegenseite schickt, die anschließend den Payload-Teil unverändert zurücksendet,[1] womit periodisch abgeprüft werden kann, ob die Verbindung zum Server noch besteht.
Compiler der für OpenSSL verwendeten Programmiersprache C erzeugen standardmäßig keinen Code zur automatischen Überprüfung der Datenlänge. Sofern der Programmierer solche Fehler nicht explizit durch einen zusätzlichen Programmcode abfängt, wird daher auch nicht überprüft, ob die angegebene Länge der Daten mit der tatsächlichen Länge der mitgelieferten Daten übereinstimmt. Ist die angegebene Länge größer als die tatsächliche Länge, so kopiert die OpenSSL-Implementierung über das Ende des Eingabepuffers hinaus Daten aus dem Heap in den Ausgabepuffer. Aufgrund der fehlenden Überprüfung kann ein Angreifer mit einer Anfrage bis zu 64 kByte[2] des Arbeitsspeichers der Gegenstelle auslesen.[3] Der Angriff kann mehrmals hintereinander durchgeführt werden, um mehr Speicher auszulesen. In Tests gelang es damit unter anderem, den privaten Schlüssel des Serverzertifikats, Benutzernamen und Passwörter von Servern auszulesen.[4]
Der Quellcode, der den Fehler aufweist, wurde am 31. Dezember 2011 von dem einzigen fest angestellten Mitarbeiter des OpenSSL-Teams aus dem Entwurfszweig in das OpenSSL-Git-Repository eingepflegt[5] und erstmals am 14. März 2012 mit OpenSSL-Version 1.0.1 veröffentlicht. Der Code wurde zuvor von einem Studenten der Fachhochschule Münster und der Universität Duisburg-Essen im Rahmen der Vorarbeiten zu seiner Dissertation über das SCTP-Protokoll entwickelt und als Entwurf bei OpenSSL eingereicht. Er erweitert OpenSSL um ein Heartbeat-Verfahren.[6] Das Verfahren wurde von dem Studenten und zwei Mitautoren in RFC 6520[1] spezifiziert und ermöglicht es in TLS und DTLS, zu erfragen, ob die Gegenseite noch erreichbar ist. So werden z. B. die Verbindungszustände von eventuell in die OpenSSL-Kommunikation involvierten NAT-Routern aufgefrischt, damit die Verbindung bei einer vorübergehenden Inaktivität nicht gelöscht wird. Bei DTLS kann das Heartbeat-Verfahren zur Path MTU Discovery verwendet werden.[1] In der Dissertation begründet der Programmierer Designentscheidungen in der Heartbeat-Spezifikation, unter anderem den Einsatz des Padding-Felds, als Schutz vor Known-Plaintext-Angriffen.[6]
Bei der Sicherheitslücke handelt es sich um einen lesenden Zugriff über die Grenzen eines Datenpuffers (buffer over-read). Anders als bei einem Pufferüberlauf werden keine Daten außerhalb von Puffergrenzen geschrieben. Der Programmierer erklärte, er habe einen unabsichtlichen Programmierfehler begangen und die Prüfung einer Eingabevariable versäumt,[7][8] in der die Länge des zurückzuliefernden Puffers mitgeteilt wird. Sein Fehler sei zwar trivial, aber folgenreich gewesen. Ferner stellte er fest, dass sein Fehler offensichtlich deshalb nicht bemerkt worden sei, weil zu wenige Menschen den Code von OpenSSL tatsächlich überprüfen.
OpenBSD- und OpenSSH-Entwickler Theo de Raadt bezeichnete in diesem Zusammenhang das OpenSSL-Team als nicht verantwortungsbewusst, da dieses einen Sicherheitsmechanismus, der bei der Entwicklung diesen Fehler nicht zugelassen hätte, aus Gründen der Leistung explizit umgehe.[9] Das OpenSSL-Team verwendete eigene Funktionen zur Speicherallokation (malloc) und -deallokation (free) und umging damit mögliche Schutzmechanismen des Betriebssystems. Das OpenSSL-Team wies auf zu wenig Ressourcen als strukturelles Problem bei der Entwicklung der Software hin und bat um finanzielle Unterstützung.[10]
Am 7. April 2014 hat das OpenSSL-Team einen Sicherheitshinweis des Inhalts herausgegeben, dass die OpenSSL-Versionen 1.0.1 bis einschließlich 1.0.1f, sowie 1.0.2-beta bis einschließlich 1.0.2-beta1[11] vom sogenannten Heartbleed-Bug[12] betroffen seien. Es ist jedoch möglich, OpenSSL ohne die fehlerhafte Heartbeat-Komponente zu kompilieren (-DOPENSSL_NO_HEARTBEATS
), eine so kompilierte Version war dadurch auch gegen einen Heartbleed-Angriff immun.[13]
Die Sicherheitslücke bestand insgesamt 27 Monate, bis sie unabhängig voneinander von Antti Karjalainen (Codenomicon, Oulu, Finnland) und Neel Mehta (Google Security) entdeckt[14][15][16] und behoben wurde.[17] Bereits vor dem öffentlichen Bekanntwerden des Fehlers waren einige Anbieter informiert,[18] die daraufhin bereits ihre Systeme absicherten.[19]
Der Kryptologe und Sicherheitsexperte Bruce Schneier beschreibt die Tragweite des Heartbleed-Bug als:
“Catastrophic is the right word. On the scale of 1 to 10, this is an 11.”
„Katastrophal ist das richtige Wort. Auf einer Skala von 1 bis 10 ist dies eine 11.“
Abgesehen von möglicherweise abgegriffenen Zugangsdaten (Benutzernamen, Passwörter) kann mit dem privaten Schlüssel des Serverzertifikats ein auch lange vor dem Bekanntwerden des Fehlers aufgezeichneter Datenverkehr nachträglich entschlüsselt werden, sofern die Verschlüsselung nicht mit Perfect Forward Secrecy geschützt war. Außerdem können mit dem privaten Schlüssel des Serverzertifikats Man-in-the-middle-Angriffe durchgeführt werden, sofern das Serverzertifikat noch nicht abgelaufen oder widerrufen ist. Es können alle Dienste betroffen sein, wie beispielsweise E-Mail-Verkehr oder verschlüsselte Chats, sofern eine betroffene OpenSSL-Version verwendet wurde. SSH ist nicht betroffen, da es TLS nicht verwendet.[21]
Das Abgreifen von Daten hinterlässt auf einem angegriffenen System kaum Spuren. Daher ist nicht sicher, in welchem Maß der Fehler ausgenutzt wurde.[22][23] Es gibt Hinweise auf einen Missbrauch im November 2013.[24] Die Nachrichtenagentur Bloomberg berichtete unter Berufung auf „zwei informierte Personen“, dass der Heartbleed-Bug praktisch von Beginn an durch die NSA genutzt wurde,[25] was vom Büro des NSA-Direktors jedoch umgehend dementiert wurde.[26][27] In einer im September 2014 veröffentlichten Studie kommen mehrere Sicherheitsforscher zu dem Ergebnis, dass es keine Hinweise auf ein Ausnutzen des Fehlers vor dessen Veröffentlichung gebe.[28]
Private Schlüssel der Serverzertifikate und möglicherweise auch andere Zugangsdaten müssen als kompromittiert betrachtet werden. Es wurde empfohlen, diese auszutauschen. Sicherheitsbewusste Anwender sollten ihre Passwörter ändern.[29] Durch die hohe Anzahl betroffener Systeme stellte dies im April 2014 auch professionelle Zertifikatsanbieter vor Herausforderungen.[30]
Im Rahmen von Heartbleed wurde auch auf die unzureichenden Möglichkeiten zur Prüfung auf zurückgezogene Serverzertifikate (CRL und OCSP) hingewiesen.[31][32]
TLS-Verbindungen dienen nicht nur der abgesicherten Verbindungsaufnahme mit einem Webserver. Auch VoIP-Telefone, Netzwerkdrucker und Router, die zur Authentifizierung Varianten des EAP-Protokolls verwenden, sind von der Sicherheitslücke betroffen.[33] Der portugiesische Sicherheitsexperte Luis Grangeia zeigte an einem Konzeptbeispiel, wie damit übertragene private Schlüssel und Zertifikatsinhalte auslesbar sind.
Um den Quellcode der OpenSSL-Bibliothek von nicht benötigten Bestandteilen zu bereinigen, erstellte das OpenBSD-Team den Fork LibreSSL. Der Quellcode wurde um mehr als 90.000 Zeilen bereinigt (Stand 21. April 2014).[34]
Bedingt durch den Heartbleed-Bug wurde der Quellcode von OpenSSL in der Folgezeit intensiver überprüft und so wurden im Juni 2014 noch weitere Lücken entdeckt und geschlossen,[35] darunter weitere des Programmierers, der auch den Heartbleed-Bug verursacht hat.[36]