Autsch ... Der GAU für Verschlüsselung im Web: Horror-Bug in OpenSSL

[Saugkraft]

Du solltest genau diesen realen User in die Testmannschaft aufnehmen.

Das hab ich probiert. Als er vom User zum Tester wurde, hat erwartungsgemäß Murphys Law gegriffen und er hat keine Fehler mehr produziert.

Aber wir wissen ja: Computer tun das, was du ihnen sagst. Nicht das was du willst.

 

[Lofgard]

Jedes System, das einen verwundbaren Server ansurft und sich richtig identifiziert ist verwundbar, da der Speicher des Servers ausgelesen wird. Also 10.9.2 als Client nützt nicht viel, als Webserver wohl schon. War bestimmt so gemeint, aber nicht das die Macuser meinen sie hätten damit nichts zu tun…

Es ist vielleicht ein "kleiner Fehler", allerdings scheinbar ein Fehler in einer Funktion die gar keinen Sinn macht. Das wirkt doch schon anders.

 

[magheinz]

Was ich nicht verstehe ist,
ich hab mich z.B. bei tumblr vor drei Wochen eingeloggt mit E-mail und Passwort.
Seit dem nicht mehr.
Jetzt ist dieser Fehler bekannt - kann denn jetzt jemand das Passwort finden,
obwohl ich es grad gar nicht eingebe? Ich mein, liegt mein Passwort in echt,
lesbar irgendwo auf einem Server von tumblr?

kann doch nicht sein!

das der Fehler jetzt öffentlich wurde bdeutet leider nicht das er nicht vorher bekannt war. Ergo: alle Passwörtet ändern.du kannst ja auch nicht mehr nachvollziehen welche server in dem Zeitraum in dem die Lücke vorhanden war mal eine verwundbare Verion der openssl-lib eingesetzt hat. Die meisten hsben ja nur geschaut welche Version hum Zeitpunkt der Veröffentlichung eingesegzt wurde. Die Lücke ist aber ja älter. Ich habe z.B. einen Server der zwischendrinn mal mit Suse statt mit debian lief, der war in der Zeit wohl verwundbar, zum Zeitpunkt der Meldung aber nicht...

 

[kleinerkathe]

Wobei man sich ja schon irgendwie wünschen würde, dass solch sicherheitsrelevanten Abläufe nicht in einer Sprache mit direktem Speicherzugriff geschrieben sind, die solche Fehler vergleichsweise einfach und schwierig zu entdecken macht?

Es würde reichen wenn man nicht versuchen würde das Rad selber neu zu erfinden. Soll heißen bei OpenSSL wurde bewusst(?) auf etwas verzichtet, was exakt das hier verhindert hätte.
http://article.gmane.org/gmane.os.openbsd.misc/211963

 

[xentric]

Es würde reichen wenn man nicht versuchen würde das Rad selber neu zu erfinden. Soll heißen bei OpenSSL wurde bewusst(?) auf etwas verzichtet, was exakt das hier verhindert hätte.
http://article.gmane.org/gmane.os.openbsd.misc/211963

Und? Da steht doch genau, wieso die ihr eigenes malloc geschrieben haben, weil es scheiße langsam unter OBSD ist. Und dann kommen wieder alle, und meckern wegen der Performance. Nimm als Beispiel das Forum hier. Immer noch keine SSL Anmeldung, die Daten gehen in fast Plaintext über die Leitung..

 

[kleinerkathe]

Nochmal lesen?
Der eigene hinzugefügte Wrapper kann nicht mal deaktiviert werden auf den Plattformen bei denen es eben kein Performanceproblem gibt. Das Performanceproblem ist nur auf manchen Plattformen vorhanden, dafür wurde die eigene Speicherverwaltung eingebaut. Dass die eigene Speicherverwaltung aber plötzlich auch Standard für alle anderen wird ist ... naja ...

 

[xentric]

Und, was ändert das an meiner Aussage... nichts? Der Grund für das OPENSSL_malloc bleibt der gleiche.

 

[Kaito]

Dass die eigene Speicherverwaltung aber plötzlich auch Standard für alle anderen wird ist ... naja ...

Zwei Systeme pflegen wäre Unsinn, sofern das eine nicht signifikante Nachteile für diese Systeme hätte.

 

[Franken]

das der Fehler jetzt öffentlich wurde bdeutet leider nicht das er nicht vorher bekannt war. Ergo: alle Passwörtet ändern.du kannst ja auch nicht mehr nachvollziehen welche server in dem Zeitraum in dem die Lücke vorhanden war mal eine verwundbare Verion der openssl-lib eingesetzt hat. Die meisten hsben ja nur geschaut welche Version hum Zeitpunkt der Veröffentlichung eingesegzt wurde. Die Lücke ist aber ja älter. Ich habe z.B. einen Server der zwischendrinn mal mit Suse statt mit debian lief, der war in der Zeit wohl verwundbar, zum Zeitpunkt der Meldung aber nicht...

vielen Dank für Deine Antwort.


@ all
Meine eine Frage bleibt aber noch offen.
Liegen denn die Passwörter unverschlüsselt auf den Servern rum?
Mit meinem laienhaften Verständnis: Wenn Passwörter verschlüsselt hinterlegt sind
dann bringt doch das Auslesen des Speichers nichts!?

Wie gesagt, in diesen Dingen bin ich ein Super-normal-User.

 

[magheinz]

sie werden aber doch überzragen. du tippdt es ein und schickst es an den server. dabei ist es ansich unvetschlüsselz.

 

[Franken]

sie werden aber doch überzragen. du tippdt es ein und schickst es an den server. dabei ist es ansich unvetschlüsselz.

Das meine ich ja. Also sind die Passwörter dann nur vor Dieben ungeschützt beim Übertragen und nicht beim nur-auf-dem-Server liegen.

 

[sir.hacks.alot]

Das meine ich ja. Also sind die Passwörter dann nur vor Dieben ungeschützt beim Übertragen und nicht beim nur-auf-dem-Server liegen.

Natürlich ist das nicht so. Ansonsten könnte man keine sicheren Passwörter haben. Bei SSl Verschlüsselung werden Passwörter verschlüsselt übertragen und dann auf dem Server entschlüsselt. Auf dem Server sind sie überhauptnicht gespeichert, sondern nur ein sogenannter Hashwert. Die Passwörter landen während der Anmeldung für einen kurzen Moment in den Arbeitsspeicher des Rechners und liegen dann unverschlüsselt vor. Das Problem besteht darin, daß dieser Speicher durch den Bug ausgelesen werden kann.

 

[Kaito]

Schon in der Vergangenheit sind immer wieder Betreiber negativ dadurch aufgefallen, einen Hash zu nutzen, von dem man wieder auf das Passwort kommen kann (z.b. Adobe). Das hat zwar nichts mit diesem Bug zu tun, ist aber eine generelle Gefahr die stetig existiert.

 

[ihatewintel]

Bringt's eigentlich irgendwas (in Sachen Sicherheit), wenn ich in der Schlüsselbundverwaltung alle Zertifikate lösche? Sorry, wenn die Frage extrem schwachsinnig sein sollte - ich bin nur ein harmloser User...

 

[sir.hacks.alot]

Bringt's eigentlich irgendwas (in Sachen Sicherheit), wenn ich in der Schlüsselbundverwaltung alle Zertifikate lösche? Sorry, wenn die Frage extrem schwachsinnig sein sollte - ich bin nur ein harmloser User...

Nein, denn die Zertifikate sind dafür da festzustellen ob dein Gegenüber(Server) tatsächlich derjenige ist, der er vorgibt zu sein, sie haben nichts mit den Passwörtern zu tun, die ausgespäht worden sein könnten.

 

[ihatewintel]

Nein, denn die Zertifikate sind dafür da festzustellen ob dein Gegenüber(Server) tatsächlich derjenige ist, der er vorgibt zu sein, sie haben nichts mit den Passwörtern zu tun, die ausgespäht worden sein könnten.

Ah - danke schön. Wieder was dazugelernt.

 

[JackTirol]

Ein interessanter Artikel zu den Hintergründen von Heartbleed und die Frage, was die NSA (eventuell) damit zu tun hat. Wer weiß, was da sonst noch auf uns zu kommt oder aber bereits am Laufen ist …

 

[stonefred]

Jetzt wollte ich gemütlich den Heartbleedbug an eigenen Servern nachvollziehen und sehe, dass nur neue Debianversionen betroffen waren. OpenSSL 0.9.x war überhaupt nie betroffen. Genauso vSphere erst nach 5.1. Schade.