Das Vertrauen in Sicherheit im Internet hat es derzeit nicht leicht: NSA und andere Geheimdienste schnorcheln unsere Onlinekommunikation mit, in Deutschland wurde kürzlich bekanntgegeben, man habe 18 Millionen kompromittierte Nutzeraccounts gefunden und gestern kam die Hiobsbotschaft eines schwerwiegenden Sicherheitslecks in OpenSSL.
OpenSSL ist eine freie Implementierung des TLS-Protokolls. Transport Layer Security, das früher Secure Socket Layer hieß, ist ein Protokoll zur verschlüsselten Datenübertragung im Internet. Das Verfahren begegnet uns häufig, nämlich immer dann, wenn eine https-Verbindung aufgebaut wird. Das bedeutet, dass Daten verschlüsselt und authentifiziert vom Browser zum Webserver übertragen werden. Wird kein TLS genutzt, kann mitgeschnittener Netzwerkverkehr einfach im Klartext gelesen werden. Besonders in öffentlichen WLANs, in die sich jeder einwählen kann, ist das ein ernstes Problem.
Gestern gab OpenSSL bekannt, dass Sicherheitsingenieure des finnischen IT-Sicherheitsunternehmens Codenomicon und Neel Mehta von Google Security einen Bug gefunden haben, der die durch TLS-Nutzung angenommene Vertraulichkeit und Authentizität gefährdet:
A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.
Der Bug wurde „Heartbleed Bug“ getauft, nach der Heartbeat-Erweiterung durch die er eingeführt wurde. Er kann dazu führen, dass durch Auslesen des oben erwähnten Speichers die privaten Schlüssel eines TLS-Servers extrahiert werden können. Aber auch Nutzernamen, Passwörter und andere sensible Informationen können sich in den angreifbaren 64k befinden. Denn der Angriff ist nicht auf einmalige Durchführung limitiert, sodass beliebig viele Speicherstückchen ermittelt werden können bis die gewünschte Information ermittelt wurde. Die Ingenieure von Codenomicon führten einen Selbsttest durch und brachten daraufhin den Ernst der Lage deutlich zum Ausdruck:
Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.
Wer sich für die technischen Details interessiert, findet auf dem existentialize-Blog eine detaillierte Analyse.
Der Bug betrifft die SSL-Versionen OpenSSL 1.0.1, die im März 2012 veröffentlicht wurde, bis 1.0.1f. Frühere Versionen sind nicht gefährdet, da sie die fehlerhafte Heartbeat-Erweiterung noch nicht enthalten. Eine Version 1.0.1g, die den Bug behebt, wurde von den Entwicklern bereits zur Verfügung gestellt. Ob es bisher wirklich zu einer Ausnutzung des Sicherheitsproblems kam, ist nicht bekannt, da ein solcher Angriff keine Spuren hinterlässt.
Arma, einer der Entwickler des Tor-Projektes, empfiehlt, sich innerhalb der nächsten Zeit vorsichtig im Internet zu bewegen und im Zweifel von der Nutzung fernzuhalten, falls man auf starke Anonymität angewiesen sei, denn die Anonymisierung durch Tor könnte durch Rechner mit der sicherheitskritischen TLS-Implementierung eingeschränkt sein. Auch das Update anderer Dienste, die noch auf der anfälligen OpenSSL-Implementierung basieren, wird nicht von jetzt auf gleich vonstatten gehen, denn zahlreiche Internet-Anwendungen, dabei Mailprogramme und Browser dürften betroffen sein. Zusätzlich steht für Serverbetreiber die Frage im Raum, ob ihre privaten Keys durch die Sicherheitslücke eventuell in falsche Hände geraten sind, Zertifikate sollten demnach sicherheitshalber ausgetauscht werden.
Die Nachricht von der Sicherheitslücke in OpenSSL ist ein Schock für viele, denn die Kryptobibliothek genießt eine weite Verbreitung. So ist sie Standard bei vielen Linux-Distributionen und Apache Webservern, die mit 38,2% die am meisten genutzten Webserver-Implementierungen sind, sowie bei ebenfalls weit verbreiteten nginx-Servern, die gemeinsam eine Abdeckung von 66% erreichen, wobei nicht alle zwingend die betreffenden OpenSSL-Versionen nutzen.
„Heartbleed“ ist nicht der erste Bug, der in OpenSSL gefunden wurde. Im letzten Jahr wurden zwei Schwächen in Zufallszahlengeneratoren entdeckt, einer davon war der durch die NSA kompromittierte Pseudozufallszahlengenerator Dual_EC_DRBG. Die Sicherheitslücken sind aber nicht der einzige Kritikpunkt. Es gab geteilte Meinungen beim Vorgehen von OpenSSL bei der Benachrichtigung über den Bug.
Der große Serverbetreiber CloudFlare wurde beispielsweise im Vorhinein über die Sicherheitslücke informiert und hatte Zeit, sie bis zur öffentlichen Bekanntgabe zu schließen. Es herrscht Uneinigkeit, ob das von besonderem Verantwortungsbewusstsein zeugt oder kleinere nicht informierte Dienste unfair im Nachteil lässt. Ebenso steht in der Kritik, dass openssl.org bisher immer noch selbst die gefährdete Version der Programmbibliothek nutzt, wie man mit einem Testtool feststellen kann.
Im Fall dieses schwerwiegenden Bugs zeigt sich, wie dringend es einer sorgfältigen Auditierung von kryptographischen Bibliotheken bedarf. Es wäre falsch jetzt danach zu schreien, andere Software zu nutzen, die den derzeitigen Bug nicht enthält, denn wie der Informatiker Dijkstra bereits sagte:
Durch Testen kann man stets nur die Anwesenheit, nie aber die Abwesenheit von Fehlern beweisen.
Es gilt, sich darauf zu konzentrieren, bewährten und soliden Code weiter zu verbessern und unermüdlich nach Fehlern und Hintertüren Ausschau zu halten.
(Wir wissen, dass wir das Problem auch haben. Wir arbeiten dran.)
@Administratoren:
Es ist sehr schön, dass Ihr hier über die OpenSSL-Schwachstelle CVE-2014-0160 berichtet. Ihr wisst aber schon, dass Euer Server (https://netzpolitik.org) mit Stand 08.04.2014, 13:35 Uhr verwundbar ist, oder?
– Kelran
Ja, deshalb steht das auch als Anmerkung im Artikel…
Ich meinte damit, dass Euer Server _immer noch_ verwundbar ist. Braucht Ihr Unterstützung? Falls ja -> E-Mail :-)
– Kelran
Die können da bestimmt auch nicht viel machen, da sie die Webseite bestimmt bei einem Anbieter hosten lassen und keinen Root-Zugriff haben.
Der Anbieter muss aktualisieren.
Nur so aus Neugierde: Ihr seid bei der Hetzner Online AG?
In jedem Fall ist das ein ziemliches Armutszeugnis für den Provider. Ihr könnt dann natürlich wirklich nichts machen.
– Kelran
Danke, Admin setzt sich dran, der ist aber gerade auf dem Kinderspielplatz.
Naja, so schlimm ist es hier nicht. Worst case waere evtl. eine Uebernahme einer Session von einem eingeloggtem Nutzer/Admin …
Aktuell ist es auch noch sehr schwer die Patches einzuspielen, wenn man nicht gerade von Hand kompilieren möchte. Bei Debian sind die Pakete erst in testing und unstable und bei Ubuntu sind sie garnicht im Repository. Ich denke das ist Morgen besser!
Ich hatte bei Hetzner bereits gestern die Patches in der Repo o.o
Gefunden bei blog.fefe.de
Wer hat eigentlich diesen OpenSSL-Code geschrieben, wegen dem jetzt alle Keys kompromittiert sind? Ein Typ namens Robin Seggelmann. Kann mal passieren, ich will jetzt nicht mit dem Finger auf den zeigen. Aber es sollte vielleicht mal jemand den anderen Code auditieren, den der so geschrieben hat.
Hier ist der git commit. Das ist aber nicht der Punkt hier gerade.
Wo arbeitet der? Was meint ihr? Kommt ihr NIE drauf!
Robin Seggelmann
T-Systems International GmbH
Fasanenweg 5
70771 Leinfelden-Echterdingen
DE
Update: Eine Sache noch. Nehmen wir mal an, jemand würde mich bezahlen, eine Backdoor in OpenSSL einzubauen. Eine, die auf den ersten Blick harmlos aussieht, die aber ohne Exploit-Schwierigkeiten auf allen Plattformen tut und von den verschiedenen Mitigations nicht betroffen ist. Genau so würde die aussehen.
Ich sehe in dem Code nicht mal den Versuch, die einkommenden Felder ordentlich zu validieren. Und auch protokolltechnisch ergibt das keinen Sinn, so eine Extension überhaupt zu definieren. TCP hat seit 30 Jahren keep-alive-Support. Es hätte also völlig gereicht, das für TLS über UDP zu definieren (und auch da würde ich die Sinnhaftigkeit bestreiten). Und wenn man ein Heartbeat baut, dann tut man da doch keinen Payload rein! Der Sinn von sowas ist doch, Timeouts in Proxy-Servern und NAT-Routern vom Zuschlagen abzuhalten. Da braucht man keinen Payload für. Und wenn man einen Payload nimmt, dann ist der doch nicht variabel lang und schon gar nicht schickt man die Daten aus dem Request zurück. Das ist auf jeder mir ersichtlichen Ebene völliger Bullshit, schon das RFC (das der Mann auch geschrieben hat), das ganze Protokoll, und die Implementation ja offensichtlich auch. Aus meiner Sicht riecht das wie ein Backdoor, es schmeckt wie eine Backdoor, es hat die Konsistenz einer Backdoor, und es sieht aus wie eine Backdoor. Und der Code kommt von jemandem, der bei einem Staatsunternehmen arbeitet, das für den BND den IP-Range betreut (jedenfalls vor ein paar Jahren, ob heute immer noch weiß ich nicht). Da muss man kein Adam Riese sein, um hier 1+1 zusammenzählen zu können.
Update: Es stellt sich raus, dass der Mann damals noch an seiner Dissertation geschrieben hat und an der Uni war und erst später bei T-Systems anfing. In der Dissertation geht es unter anderem um die Heartbeat-Extension, die mit UDP begründet wird. In dem Text steht auch drin, dass man keine Payload braucht. Aber lasst uns das mal trotzdem so machen, weil … Flexibilität und so! (Danke, Jürgen)
@ Admins:
Bitte LÖSCHT die Adresse sowie den Namen aus dem Kommentar!!! Es kann ja wohl nicht sein, dass der Kollege über mir hier öffentlichen an den Pranger gestellt wird.
@ EDGE: Ich verkneife mir zu Deiner Handlung mit der Veröffentlichung des Namens und der Adresse jeden Kommentar…
Wieso sollte das gelöscht werden? Darf man den Hersteller von einer Sicherheitslücke in Deutschland nicht bennen, wenn ja nach welchem Recht? Darf man auch nicht mehr darüber berichten wenn Volkswagen kaputte Autos ausliefert?
Weil das unterste Gürtellinie ist, jemanden an den Pranger zu stellen?
Außerdem: Wo waren die ganzen Schlaumeier, die jetzt rumheulen, denn bevor der Bug (ja, ein Bug, keine absichtliche Backdoor) überall breitgetreten wurde? Ihr hättet ja auch den Code von alleine prüfen können – ach richtig, da fehlt euch ja die Kompetenz dazu…
Wo Menschen arbeiten, passieren Fehler. Und es ist etwas anderes, ob VW kaputte Autos ausliefert oder jemand in seiner Freizeit / im Rahmen seiner privaten Dissertation etwas implementiert und dies fehlerhaft ist.
T-Systems hat damit rein gar nichts zu tun…
Dann hätte der Herr Seggelmann vielleicht keinen Code bei OpenSSL einreichen sollen, schließlich kann man sich das direkt aus dem öffentlichen Git-Repository von OpenSSL holen:
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1
Aber nein, wir dürfen auf keinen Fall Personen direkt für miserable Arbeit kritisieren! Immer schön kuscheln, dann wird alles gut!
Nachtrag:
Und wenn jemand in seiner Freizeit an einer derart kritischen und sensiblen Sache wie OpenSSL rumbastelt und Mist baut ist das weniger schlimm als wenn andere Produkte fehlerhaft sind?!?!?!?
Herr/Frau Flo sollte vielleicht mal mit einen fähigen Kryptographen oder Sysadmin fragen warum Heartbleed so viel Aufregung verursacht…
@Flo: Die genannte Adresse ist natürlich nicht die Privatanschrift von Robin, sondern die Adresse seines Arbeitgebers T-Systems. Man könnte zwar darüber diskutieren, ob man ihn Robin S. abkürzen sollte, allerdings ist der volle Name (für jeden, der Ahnung vom Thema hat) jederzeit über die entsprechenden Edits offen einsehbar: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4817504d069b4c5082161b02a22116ad75f822b1
Klar sollte man aufpassen, dass man ihn nicht vorschnell zum Buhmann macht, schließlich gehört er zu den wenigen, die aktiv am Code mitgearbeitet haben, statt nur andere arbeiten zu lassen.
Andererseits ist das aber ein solch kurioser und zugleich schwerwiegender Fehler, dass man sich tatsächlich auch über die Hintergründe Gedanken machen sollte und sich dann natürlich auch die beteiligten Einreicher ansehen muss. Würde es sich nur um einen klassischen Bug handeln, wäre das natürlich völlig überzogen, aber hier bin haben wir eine Grauzone, bei der man gute Argumente dafür und dagegen haben kann.
Da fehlt aber was, Fefe schreibt dazu mehr.
Zitat:
Update: Echte Verschwörungstheoretiker lassen sich natürlich von sowas nicht aufhalten. Der Job bei T-Systems war dann halt die Belohnung!1!! Und echte Verschwörungstheoretiker googeln auch dem Typen hinterher, der den Code auditiert und durchgewunken hat, damit der eingecheckt werden konnte. Ein Brite, der nur 100 Meilen von Cheltenham (GCHQ-Sitz) entfernt wohnt!!1! (Danke, Jürgen)
Ja und? Verbreiten wir jetzt hier Verschwörungstheorien??
Wer ist denn bitte „wir? Ich habe nur das Zitat aus blog.fefe.de vervollständigt weil ein Teil hier gefehlt hatte. Was du als „Verschwörungstheorie verbreiten“ bewertest sei dir selbst überlassen.
Fefes Blog zu lesen, kann ich nur empfehlen, wenn man regelmäßig netzpolitik liest. Dann wäre man auch nicht so erstaunt über Fakten wie den Namen eines Programmierers.
Allerdings setzt Fefe einiges an Knowhow voraus, das man sich u.U. erarbeiten muss. So ist das mit Technik.
Wer also hier rumjammert, dass Programmierer und späterer Arbeitgeber hier nicht genannt werden dürfen, hat sich erstens sicher noch nie mit offener Software beschäftigt und zweitens ganz sicher die Tragweite des „Fehlers“ nicht verstanden.
Fefe erläutert das gut, für einige muss man es aber wohl drastischer formulieren: Der Programmierer hat in die betroffene Funkion einen Datenabgleich eingebaut, der völlig unnötig ist und dazu noch einen gravierenden Fehler, durch den sich der Datenabgleich noch beliebig missbrauchen lässt.
Wer im Jahr 1 nach Snowden noch glaubt, kryptografische Software unterliegt vor allem menschlichen Fehlern, hat sicher auch noch nie etwas vom Skandal um RC4 gehört. Womit wir wieder beim Knowhow wären, dass sich einige weigern anzueignen und lieber jammern und zetern.
Hat sicherlich eine wahre Seite….aber ich würde nicht soweit gehen, ab sofort hinter jedem Bug in kryptografischer Software direkt eine getarnte Hintertür zu vermuten. Als ob Fehler nicht passieren können, ist doch bei jedem Produkt nicht anders. Ich muss da immer an die Raumfahrt denken (Ariane 5 oder Mars Climate Orbiter z.B.). Da wurden Millionen in die Entwicklung gesteckt und was hats gebracht ;-)
Wie überall, gibs in der Softwareentwicklung (auch im OpenSource Bereich) nicht immer eine lückenlose Qualitätsüberprüfung (wie auch). Ist halt so.
Du wirst selten einwandfrei feststellen können, obs jetzt einfach nur mensch. Versagen gewesen ist oder eine gekaufte Hintertür. Wir kennen seit langem viele Beispiele, wo irgendwo in der Produktionskette einfach was schief gelaufen ist. Und seit kurzem kennen wir viele Beispiele dafür, was Geheimdienste so alles anstellen. Gibt also zwei Seiten der Medaille…
Typisch Fefe! Ich wohne nur 30km vom Dagger-Komplex entfernt. Da bin ich ja wohl höchstverdächtig.
Machst du von da auch (fehlerhaftes) Code-Auditing für Sicherheitslücken? Der Dagger-Komplex ist außerdem US-Gebiet, während du wohl auf BRD-Gebiet wohnst.
Der sogenannte „Dagger-Komplex“ gehört völkerrechtlich ohne Zweifel zum bundesdeutschen Staatsgebiet, gleiches gilt übrigens auch für hiesige ausländische Botschaften.
Da die Weltregierung nur Geld und Energie für Unterdrückung ausgibt, hat sie natürlich nichts mehr für wahre Sicherheit übrig.
Mit der Veröffentlichung des Namens des Entwicklers und seines Arbeitgebers, der den OpenSSL-Bug eingebaut haben sollte, gehen sie etwas zu weit.
Schließlich durchläuft das Eingestellte einen Review-Prozess, ein sogenanntes Vieraugenprinzip, wenn es nur Vieraugen sind.
Also wenn sie schon auf diese Ebene herabsinken, dann sollten sie alle Verantwortlichen benennen, aber eigentlich sollten sie Veröffentlichungen dieser Art überhaupt nicht machen.
Ich hoffe, dass diese Veröffentlichung nicht unbeantwortet bleibt.
M. Przibylla
Offensichtlich haben sie bei diesem Thema einige Punkte inhaltlich nicht ganz verstanden:
1. Es ist belegt, wer das war und er hat es auch selber bestätigt. Es handelt sich also keineswegs um ein Vermutung, sondern um eine Tatsache.
2. Der Name ist in der Versionsgeschichte hinterlegt und dort auch öffenltich für jeden einsehbar.
3. Wenn sie die Nennung aller Verantwortlichen wünschen, ist das kein Problem, das wurde auch bereits gemacht, es handelt sich beim zweiten Beteiligten um den Briten Dr. Stephen Henson. Auch der ist in der Versionsgeschichte hinterlegt und öffentlich einsehbar.
4. Bei der Nennung des Arbeitgebers würde ich ihrer Argumentation sogar zustimmen – wenn, ja wenn es nicht leider gerade sehr relevant für den Fall wäre, dass der Entwickler kurz nach seiner Arbeit bei einem „staatsnahen“ Betrieb engagiert wurde, der für Kontakte mit Behörden und behördennahen Organisationen bekannt ist. Hier wurde offenbar eine Abwägung getroffen, die man in einem anderen Fall anders sehen würde, hier aber durchaus vertreten kann. Wie hätte man sonst auf diesen kuriosen Zusammenhang hinweisen sollen? Ihn verschleiern oder mysteriöse Andeutungen machen, welche nur noch mehr Gerüchte befeuern würden?
5. Der Grund, warum es durchaus legitim ist, hier mehr Transparenz zu schaffen als bei einem Allerwelts-Fehler, ist erstens die Schwere und Art und Weise des implantierten Fehlers und der Hintergrund des Entwicklers, der hier relevant ist. Der hat nämlich zu der Zeit als er diesen Fehler eingebaut hat, auch seine Doktorarbeit geschrieben, in der er eben beschreibt, wie man es richtig macht – also konträr zu dem, was sein Eintrag zu OpenSSL war. Man könnte ihm zugute halten, dass sich das zeitlich überschnitten hat, aber spätestens nach kompletter Abgabe seiner Dissertation hätte er genau wissen müssen, was er da fabriziert hat. Und zwischen dem letzten Datum seiner fertigen Dissertation und der Implementierung des Fehlers lagen nur 10 Monate, in denen er auch nur eine handvoll Änderungen bei OpenSSL vorgenommen hatte. Diese Zusammenhänge sind bei dem größten Sicherheitsloch, welches das Internet jemals gesehen hat, sehr wohl erwähnenswert und kann man nur dann überprüfen, wenn man die Fakten auf den Tisch legt.
Sie dichten und interpretieren Szenarien wie in einem Taschenbuchroman, ein Komplott haben sie entdeckt, bravo.
Sie sollten sich schnellstens die Rechte schützen lassen und ab nach Hollywood.
Wenn sie wirklich das glauben was sie schreiben, dann leben sie in einer Fantasiewelt.
M.Przibylla