Ja, Code-Review oder automatisierte Tests hätten diesen Fehler wohl gefunden. Oder aber auch statische Codeanalyse, der clang ist da ja eigentlich Vorreiter und noch dazu aus dem gleichen Haus…
1 „Gefällt mir“
Man hätte den Code ja ansich nichtmal reviewen brauchen, wenn man die korrekten Compiler Flags verwendet hätte. Unreached Code und so. <_<
Bzgl. der Test cases ist der „Artikel“ anderer Meinung.
kannschonmalpassieren.jpg
traurig
TL;DR: Alle Systeme umgehend aktualisieren! (Es sei denn, ihr wollt eure Kiste für unauthentifiziertes Remote-Debugging offen halten. :-p)
Wollte ich vorhin auch hier posten, aber konnte den Thread nicht finden. 
Fand insbesondere folgenden Satz
etwas merkwürdig. Ist zwar nicht falsch, aber wenn ich Recht erinnere gabs ungefähr zur Zeit des goto-fails auch bei GnuTLS ein goto-Bug.
Ja, aktualisiert und holt euch die verwundbare SSL-Version.
Ja, also zB Debian squeeze mit OpenSSL 0.9.8 ist nicht verwundbar, da in Panik ein Update auf wheezy zu machen waer zwar kein Problem (mehr, da gefixt), aber sinnlose Panik.
Achja, und wenn man ein verwundbares System updated: Neue Zertifikate mit neuen Schluesseln erzeugen und die alten revoken.
2 „Gefällt mir“
Ja, GnuTLS hatte auch ein Problem bei der Zertifikats-Validierung, das lustigerweise durch ein [m]goto fail;[/m] gefixt wurde. Solche und andere Bugs wird es auf absehbare Zeit in allen Libraries geben, das Lesen von beliebigem Speicher ist aber natürlich schon eine besonders krasse Variante.
Der Absatz ist tatsächlich etwas merkwürdig, er ignoriert z.B. komplett die Existenz von NSS und gar so exotisch ist GnuTLS nun auch nicht (wobei, im Embedded-Bereich vielleicht schon). Was allerdings stimmt ist, dass der OpenSSL-Bug auch Client-seitig brisant ist. Da können zwar keine privaten Keys gelesen werden, womöglich aber allerhand andere Daten.
Natuerlich kanns auf Clients auch private Keys geben, gewisse CAs machen zB SSL-Client-Zertifikats-Authentifizierung (StartSSL oder CAcert). Zusaetzlich gibts noch so Dinge wie gespeicherte Passwoerter, Masterpasswoerter fuer den Passwortspeicher und natuerlich den Inhalt dazu, Cookies, Kerberos-Keys (die so gut sind wie Passwoerter fuer einen Angreifer) und irgendwelche magischen shared secrets fuer diverse Dienste.
[quote=mute]
Ja, aktualisiert und holt euch die verwundbare SSL-Version.
[/quote]Versionen die den Bug noch nicht haben können auch kein TLS > 1.0. Das ist nicht ganz so schlimm wie dieser Bug - es gilt aber genauso, dass umgehend aktualisiert werden sollte.
1 „Gefällt mir“
Stimmt, ist aber nicht sehr verbreitet. Außer bei den genannten hab ich das aber noch nirgendwo gesehen.
Und keiner der gängigen Browser benutzt OpenSSL. (Chrome ist mit dem Wechsel von NSS auf OpenSSL wohl noch nicht so weit.)
Das meinte ich mit „allerhand andere Daten“.
Ich vergaß gänzlich dieses hier zu posten. 8-(
Ist zwar inzwischen schon etwas her, aber sicherlich noch aktuell.
So intellent wird mit Heartbleed umgegangen.
Wobei es so aussieht, als wäre Heartbleed vor der öffentlichen Bekanntheit nicht (im großen Stil) ausgenutzt worden. Es war ja anfangs auch umstritten, ob man überhaupt private keys auslesen kann.
Natürlich sollte der/die verantwortungsbewusste Admin trotzdem die Schlüssel ausgetauscht haben. Ich halte es aber auch ansonsten nicht gerade für das größte Problem, sofern OpenSSL zeitnah gepatcht wurde.
Das ist Definitionssache von „im großen Stil“. Es habe wohl Beweise für das Ausnutzen einiger Verbindungen (vermutlich Nachrichtendienst/e) gegeben. Dies findet auch in dem von dir geposteten Link Erwähnung. Inwiefern diese allerdings schlüssig sind, habe ich nicht verifiziert.
Ob besagte Behörden nur einige der Kunden waren oder unter anderen den Bug selbst gefunden haben, spielt im Grunde keine Rolle. Selbst wenn man den Behörden naiv Vertraut, ist die Wahrscheinlichkeit, dass diese Lücke ausgenutzt wurde nicht kleinzureden.
Zwar konnte ich beim Überfliegen jetzt nicht wirklich eine Stelle finden, in der die Umstrittenheit erwähnt wird, dennoch schriebst du selbst „anfangs umstritten“. Woraus ich schließe, dass du diese Zweifel inzwischen für, zumindest geringfügig, unbegründet hällst. Dementsprechend kann ich deine folgende Aussage nicht nachvollziehen.
Abgesehen davon - dass zeitnah auch hier Definitionssache ist und Lücken selbstredend nicht bewusst gepatcht werden können, solange die Verantwortlichen keine Kenntnis von etwaigen Bugs, die in diesem Fall allerdings für ca. zwei Jahre lang existierten, haben - findest du es also nicht brisant, dass neben sonstig sensitiven Daten, theoretisch sogar die private keys ausgelesen werden konnten und die entsprechenden Zertifikate als kompromittiert zu gelten haben? Die Keys können auch in dem kurzen, der öffentlichkeit bekannten, Zeitraum ausgelesen worden sein. Bei falschem Umgang mit dieser Lücke, ist der verursachbare Schaden, selbst nach dem Fix noch gravierend. Phising mit gültigem Zertifikat. 
Inzwischen ist bewiesen, dass es geht. Steht auch als „Update“ ganz oben in dem verlinkten Artikel.
Ich hab das nur erwähnt, um zu zeigen, dass es nicht ganz so trivial ist, wie es auf den ersten Blick vielleicht aussieht.
Ja, die kann man als kompromittiert betrachten. Deshalb ja meine Rede von „dem/der verantwortungsbewussten Admin“.
Das Risiko für eine tatsächliche Kompromittierung halte ich aus o.g. Gründen trotzdem für überschaubar und Admins, die kein Zertifikate ausgetauscht haben, haben wohl generell keine gute Haltung zu Sicherheit. D.h. ich gehe davon aus, dass sie weitaus praxisrelevantere Probleme verursachen.
Ich hasse es, es dir zu sagen, aber das geht sowieso, weil Revocation nunmal kaputt ist.
Der echte Vorteil durch einen Wechsel des privaten Schlüssels kommt nur bei klassischem TLS ohne forward secrecy zum Tragen. Und wenn deine Admins kein forward secrecy aktivieren, sind wir imho wieder bei relevanteren Problemen.
TL;DR: Alles scheiße, aber ich würde das nicht am fehlenden Zertifikatstausch nach Heartbleed festmachen.
1 „Gefällt mir“
Ups, hatte den falschen Artikel gelesen, hatte noch was anderes auf.
:-/
Wobei bei aktivem PFS ein neuer Schlüssel ja auch nicht hilft. Der Angreifer kann mit dem alten Zertifikat sowieso einen aktiven MITM Angriff fahren und ohne einen solchen (aktiven MITM Angriff) kommt er generell nicht an den Verbindungsinhalt.