RootForum Community

Moin,

der aktuelle OpenSSL-Bug, besser bekannt als Heartbleed oder CVE 2014-0160, ist ein echter Super-GAU.
Daher möchte ich kurz auflisten wer/was überhaupt betroffen und was nun zu tun ist.

Betroffen sind ausnahmslos alle Softwarepakete welche die OpenSSL-Bibliothek in den Versionen 1.0.1 bis 1.0.0f sowie die Betaversionen von 1.0.2 verwenden.
Es gibt hierbei nur eine einzige Ausnahme: Wenn eine betroffene OpenSSL-Implemention explizit ohne die standardmässig aktivierte Heartbeat-Funktion kompiliert wurde, dann und nur dann ist sie nicht betroffen. Dies ist allerdings selten der Fall (OpenSSH, Android (nur Android-4.1.1 ist anfällig), MacOS, iOS und Windows sind derzeit die bekanntesten Ausnahmen).

Zu tun gibt es nun Einiges und es muss zwingend getan werden, ausnahmslos!
Als Erstes muss das mitlerweile verfügbare Update für OpenSSL umgehend eingespielt werden.
Als Zweites müssen sämtliche gegebenenfalls verfügbaren Updates für OpenSSL nutzende Software eingepielt werden.
Wer eine sourcebasierte Distribution oder ein BSD verwendet, muss sich auf eine längere Kompilierungsorgie einstellen. Ich empfehle hier gleich den radikalen Weg das gesamte Basissystem und sämtliche Softwarepakete zu rekompilieren (vorher natürlich die aktuellen Sourcetrees updaten/auschecken).
Als Drittes das System rebooten. Ja, rebooten, ernsthaft!
Als Viertes kommt das Ärgerlichste an diesem Super-GAU, nämlich das Austauschen sämtlicher SSL-Zertifikate, deren privater Schlüssel und Passphrasen. Hierbei ist es extrem wichtig, dass wirklich kein einziger Schlüssel oder Passphrase widerverwendet wird, denn diese waren schlimmstenfalls über zwei Jahre lang im Klartext von aussen lesbar, für jedermann.
Als Letztes bitte alle Passworte die seit Januar 2012 über eine SSL/TLS-Verbindung mit dem System ausgetauscht wurden, durch neue sichere Passworte austauschen. Ja, ausnahmslos alle! Hierzu zählen unter Anderem Passworte für E-Mail-Konten, für Weblogins, für Adminpanels, für Hilfsscripts, etc.


Update 12.04.2014 01:50 Uhr:
Auch wenn Cloudflare etwas Anderes behauptet, so war/ist auch nginx betroffen. Cloudflare verwendet eine stark modifizierte Version von nginx und hat eben auch die betroffenen Codeteile beziehungsweise die Speicherverwaltung verändert. Daher besteht für alle anderen nginx-Installationen keinerlei Entwarnung.
Auch Cloudflares Darstellung, dass sie keine Zertifikate oder Keys auslesen konnten, liegt allein an deren modifierten Version und ist somit auf keine andere Installation übertragbar.
Ebenso unterschlägt Cloudflare, dass ihre Server mit sehr viel RAM bestückt sind und dadurch den Prozessen und somit auch OpenSSL auf ihren Systemen erheblich mehr Speicher zur Verfügung steht, als dem durchschnittlichen Mietserverbetreiber. Je weniger RAM, desto grösser die Wahrscheinlichkeit, dass durch diesen Bug die Zertifikate samt Schlüssel (im Klartext!) ausgelesen werden konnten.

Update 12.04.2014 12:40 Uhr:
Mitlerweile wurde auch Cloudflares nginx als verwundbar nachgewiesen: http://www.golem.de/1404/105825



Die Liste wird bei neuen Erkenntnissen entsprechend ergänzt.

Gruss,
Joe User

Joe User wrote:Moin,

der aktuelle OpenSSL-Bug, besser bekannt als Heartbleed oder CVE 2014-0160, ist ein echter Super-GAU.
Daher möchte ich kurz auflisten wer/was überhaupt betroffen und was nun zu tun ist.

:YMPRAY:

Joe User wrote: Als Drittes das System rebooten. Ja, rebooten, ernsthaft!

%-(

Joe User wrote:Als Viertes kommt das Ärgerlichste an diesem Super-GAU, nämlich das Austauschen sämtlicher SSL-Zertifikate, deren privater Schlüssel und Passphrasen. Hierbei ist es extrem wichtig, dass wirklich kein einziger Schlüssel oder Passphrase widerverwendet wird, denn diese waren schlimmstenfalls über zwei Jahre lang im Klartext von aussen lesbar, für jedermann.

Ist das ok, wenn ich die PKI, die ich nach deiner Anleitung gebaut hab, mit in die Tonne kloppe und dann alles neu mache?

Joe User wrote:Als Letztes bitte alle Passworte die seit Januar 2012 über eine SSL/TLS-Verbindung mit dem System ausgetauscht wurden, durch neue sichere Passworte austauschen. Ja, ausnahmslos alle!

:-??

Ich mach mich dann schonmal ans kompeilern :-B

Ja, die PKI ist mit dem Bug leider komplett für die Tonne :-/

Btw. auch OpenSSH nutzt OpenSSL für die Schlüsselerzeugung und für einiges Krypto-Foo. Da der Bug aber in der TLS-Implementierung steckt, die von OpenSSH nicht genutzt wird, darf man i. d. R. davon ausgehen, dass SSH-Schlüssel und -sessions nicht kompromittiert waren (siehe http://security.stackexchange.com/quest ... 7050_55076)

OpenSSH, Android, MacOS, iOS und Windows berücksichtigt und Cloudflares Aussagen relativiert.

daemotron wrote:Btw. auch OpenSSH nutzt OpenSSL für die Schlüsselerzeugung und für einiges Krypto-Foo. Da der Bug aber in der TLS-Implementierung steckt, die von OpenSSH nicht genutzt wird, darf man i. d. R. davon ausgehen, dass SSH-Schlüssel und -sessions nicht kompromittiert waren (siehe http://security.stackexchange.com/quest ... 7050_55076)

Jaein, letztendlich war es möglich den kompletten RAM aus zu lesen. SSH ist zwar zum Ausspähen nicht verantwortlich gewesen aber das ändert nichts daran, dass der Server ausgelesen werden konnte. Wer auf dem System private keys abgelegt und ggf. genutzt hat, z.B. Sprunghost, hat hier auch Handlungsbedarf.

ddm3ve wrote:Jaein, letztendlich war es möglich den kompletten RAM aus zu lesen.

So wie ich das verstanden habe, wurden nur Speicherbereiche geleaked, die auch von libssh allokiert waren. Gute(tm) Betriebssysteme trennen die Speicherzugriffe eigentlich recht zuverlässig, so dass eben nicht der gesamte RAM-Inhalt ins Netz geblasen werden konnte.

ddm3ve wrote:SSH ist zwar zum Ausspähen nicht verantwortlich gewesen aber das ändert nichts daran, dass der Server ausgelesen werden konnte. Wer auf dem System private keys abgelegt und ggf. genutzt hat, z.B. Sprunghost, hat hier auch Handlungsbedarf.

Nur in der Konstellation, in der eine Anwendung, die gegen OpenSSL gelinkt ist und die kaputte TLS-Implementierung auch verwendet hat, die betroffenen SSH-Schlüssel dann im Speicher hatte. OpenSSH selbst tut das nicht, und eine andere Applikation sollte eigentlich die Keys nicht in die Finger bekommen. Wer das allerdings nicht ausschließen kann, muss tatsächlich auch mit kompromittierten SSH Keys (v. a. Host Keys) rechnen.

Letzter Hinweis: die in FreeBSD 8 & 9 enthaltene OpenSSL-Version (0.9.8 ) ist von diesem Problem nicht betroffen, wohl aber von einem Problem mit ECDSA, das (mal wieder) zu theoretisch vorhersagbaren Sitzungsschlüsseln führen kann. Da ECDSA nicht zum ersten Mal in dieser Hinsicht auffällig wird, würde ich auf dessen Einsatz zu Gunsten von DH_RSA bzw ECDH_RSA verzichten.

ddm3ve wrote:Jaein, letztendlich war es möglich den kompletten RAM aus zu lesen.

Nein, es kann nicht der gesamte RAM ausgelesen werden, sondern nur der von OpenSSL reservierte/genutzte Bereich des RAM.
Und wie daemotron bereits schrieb, ist OpenSSH zwar gegen OpenSSL gelinkt, deaktiviert dabei aber die anfällige Heartbeat-Funktion automatisch. Daher ist OpenSSH als solches nicht direkt von dem Bug betroffen.

Anders sieht das eventuell mit curl und anderen Apps/Libs aus, wenn sie gegen OpenSSL und libssh gelinkt sind. Dann wären die OpenSSH-Keys unter Umständen indirekt betroffen, wenn die SSH-Funktionen in curl und Co auch genutzt wurde.

Mitlerweile wurde auch Cloudflares nginx als verwundbar nachgewiesen: http://www.golem.de/1404/105825