Lücke in OpenSSL

Hi,

das dürfte interessant für jeden sein, der Server betreibt:

In erster Linie betroffen sind jetzt alle Betreiber von Servern, die SSL zur Verschlüsselung einsetzen. Das sind nicht nur Web-Server, sondern häufig auch solche für E-Mail, VPN und andere Dienste. Es ist äußerst wichtig, diese Systeme jetzt schnellstmöglichst zu sichern. Die Version OpenSSL 1.0.1g enthält den Fehler nicht mehr. Debian stellt bereits ein Update bereit; andere Distributionen werden bald folgen. Wer OpenSSL selbst mit der Option -DOPENSSL_NO_HEARTBEATS übersetzt, kann eine nicht anfällige Bibliothek erzeugen. [Update: Versionen vor der aktuellen 1.0.1 wie das auf älteren Systemen noch verbreitete OpenSSL 0.9.8 sind offenbar nicht betroffen.]

Im nächsten Zug müssen natürlich auch Endanwender, die Produkte auf OpenSSL-Basis einsetzen, aktualisierte Versionen installieren. Und das dürften nahezu alle sein. Denn das Problem betrifft nicht nur PCs, sondern insbesondere auch Smartphones, SmartTVs, Router und viele andere Geräte – im wesentlich alles, was irgendwie mit dem Internet spricht und keine proprietären SSL-Bibliotheken beziehungsweise den Exoten GnuTLS einsetzt.

Ich habe sofort geupdatet. Die Dienste auf meinem Server habe ich trotzdem erst einmal abgeschaltet, da Server und Client auf dem neuesten Stand sein müssen.

Viele Grüße,
Tim

Erm, hast überhaupt geschaut, welche Version du installiert hattest? Gut, dass ich nicht so Versionsgeil war und noch ne 0.9.8o habe ^^

Ich halte meine Kiste eigentlich immer aktuell und hatte tatsächlich auch die betroffene auf dem Server. Aber das Update ist heute Nacht schon in die Debian Repos geschoben worden, da waren sie schnell.

Edit: Naja, “Versionsgeil”… http://www.cvedetails.com/vulnerability-list/vendor_id-217/product_id-383/version_id-26306/Openssl-Openssl-0.9.8.html

Naja, die CVEs betreffend aber meist nicht nur die 0.9.8er Versionen, sondern auch höhere. Das mit der Versionsgeilheit nehmen ich zurück, da OpenSSL 1.0.1 es in Debian Wheezy geschafft hat und die sind ja eher konservativ :wink:

Btw. Abschalten müsstest deine Dienste nicht, aber neue Private Keys/Zertifikate wären angesagt.

Doch, ich sitze auf der Arbeit und habe nicht groß Zeit an meinem Server zu schrauben. Da hab ich betroffene Dienste erst mal abgeschaltet, weiter geht es dann mit dem Spaß erst heute abend nach Feierabend :wink:

Ok, das ist was anderes :slight_smile:

Meinte eher generell ^^

Weiß einer, wie die gängigen CAs sowas handhaben? Ich fänd es nicht so toll, wenn man die ganzen Zertifikate nochmal neu kaufen müsste…

GlobalSign, Thawte und Comodo tauschen kostenlos, bei anderen Anbietern ist das noch nicht klar:

Als StartSSL User scheint man Pech zu haben. Für das Wiederrufen eines Zertifikats muss man draufzahlen. Ich benutze daher für meine Dienste CaCert Zertifikate.

Würde ich wahrscheinlich auch bevorzugen. AFAIK sind die immer noch nicht beim Firefox drin. Ist für an Kunden gerichtete Seiten also nicht brauchbar.

es reicht zum Testen - habe da auch Zertifikate. Und in einem Jahr ist das eh hin ^^

Tja, halt ungeeignet für den Produktiveinsatz.

bei mir sind im Firefox drinnen - kann aber auch sein das die durch meine Anmeldung nachinstalliert wurden

AFAIK StartSSL ist schon drin, CaCert aber nicht.

Der eigentliche WTF bei diesem Bug ist meiner Meinung nach, dass OpenSSL in C (nicht einmal in C++) geschrieben ist. Ja ich weiß, systemnah, Performance, Übersetzungsaufwand, bla… Und ich weiß auch, dass definitiv Java die falsche Sprache für eine Implementierung wäre. Aber es gibt inzwischen so viele gute Alternativen (mein Favorit für den Job wäre D 2.0), wo solche “einfachen” Fehler gar nicht erst möglich wären. Bei C und (schlecht geschriebenen) C++ zu bleiben heißt, ganz bewußt in die nächste Runde des Hase-und-Igel-Spiels zu gehen. Sollte man nicht langsam anfangen, ernsthafte Konsequenzen zu ziehen statt an den Symptomen herumzudoktern?

Dir ist bewusst das dann einige Mannjahre in das neue Projekt geschoben wird. Das nur eine “paar” Programmierer die Sprache können. Das dadurch die Qualität des Codes leidet (weil wenige Ahnung von der Spache haben). Das dies zu neuen Fehlern führen wird, die ebenfalls so kritisch sein können.

Es ist egal welche Sprache es ist. Das Hase-und-Igel-Spiel geht mit jeder Sprache.

Jede Software hat ein EOL (auch wenn das nicht immer eingesehen wird). Ja, ich weiß, bei Banken und Versicherungen läuft noch COBOL, aber ist das auch wirklich sinnvoll?

Das nur eine “paar” Programmierer die Sprache können.

Ein typisches Henne-Ei-Problem.

Das dadurch die Qualität des Codes leidet (weil wenige Ahnung von der Spache haben). Das dies zu neuen Fehlern führen wird, die ebenfalls so kritisch sein können.

Soooo unterschiedlich sind die alternativen Sprachen nicht, die meisten sehen recht ähnlich aus, nur das halt der gefährlichste Nonsense einfach verboten ist, und das Verhalten der Sprache insgesamt konsistenter ist.

C ist eigentlich eine Unsprache, voller unnötiger Fallstricke und WTFs, dazu inkonsistent und schlecht definiert. Wenn man die Energie, die man aufwenden muss, um diesen Schwachsinn zu beherrschen, in eine vernünftige Sprache investiert, kommt man meiner Meinung nach schneller ans Ziel.

Es ist egal welche Sprache es ist. Das Hase-und-Igel-Spiel geht mit jeder Sprache.

Ja, aber auf einer neuen Ebene - ohne Pufferüberläufe und ähnliche Anachronismen.

Schlimmster bug aller Zeiten… Alle Passwörter sollten geändert werden. Auf einer Skala von 1 bis 10 eine 11…

*** Edit ***

Ich schreibe natürlich nicht irgendeinen Quatsch, hier sind zB drei Seiten, die von Heartbleed OpenSSL bug betroffen sind:

Site Updated Cert? Action
facebook.com YES (1 month ago) Go update!
google.com YES (2 weeks ago) Go update!
yahoo.com YES (5 days ago) Go update!

Quelle: Teilweise Webradio…

Man könnte auch einfach Sprachen nehmen die für “High Integrity”-Systeme schon seit längerem etabliert sind und sich mit relativ wenig Aufwand auf die Geschwindigkeit von den C-Programmen bringen lassen, dazu gehört z.B. SPARK (Teilmenge von ADA)

Es scheint übrigens noch mehr derartige Auffälligkeiten in der OpenSSL Implementierung zu geben, siehe http://blog.regehr.org/archives/1128

Ich habe auch erst mal alle Dienste abgeschaltet, die werden zZt eh nicht benötigt.

Kann mir jemand das mit den Zertifikaten kurz erklären? ich habe mich bisher damit gar nicht beschäftigt.