OpenSSL Heartbleed - Security-GAU - Passwörter ändern!

[AnarchX]

http://www.heise.de/newsticker/meldung/Passwort-Zugriff-Heartbleed-Luecke-mit-katastrophalen-Folgen-2166861.html
http://www.golem.de/news/openssl-wichtige-fragen-und-antworten-zu-heartbleed-1404-105740.html
http://www.cnet.de/88128840/openssl-luecke-heartbleed-auf-welchen-webseiten-sollte-man-das-passwort-aendern/

Da sollte sich wohl fast jeder in den Listen der betroffenen Seiten finden.

[joe kongo]

Supi,
der Programmierfehler besteht seit Januar 2012.
Open Source ist sicher weil dort alle reinschauen können ...
Die NSA lacht sich gerade schlapp, und vlt. der Hoppala Programmierer (Speicherbereichsüberprüfung in einem verbreiteten Verschlüsselungsmodul,
wie konnt ich das nur übersehen :redface:).

[Crushinator]

Ich habe eine gute und eine schlechte Nachricht. Zuerst die gute: Das 3DC-Forum ist nicht betroffen; wir nutzen die anfällige OpenSSL-Version nicht. In other words: Security by mehr oder weniger zufälliger Update-Faulheit! (y)

Nun die schlechte ...

[...]
http://www.cnet.de/88128840/openssl-luecke-heartbleed-auf-welchen-webseiten-sollte-man-das-passwort-aendern/
Da sollte sich wohl fast jeder in den Listen der betroffenen Seiten finden.

Einige in der Liste aufgeführte Dienste haben ihre SSL-Zertifikate noch gar nicht erneuert (wenn ich es korrekt erkenne, z.B. T-online) und empfehlen ihren Nutzern trotzdem, sie sollen ihre Passwörter ändern! WTF?! :eek:

IMHO handelt es sich dabei entweder um irrtümlich als solche verstandene Empfehlungen, oder um eine um die Hälfte der Aussage gekürzte Wiedergabe der Empfehlung, oder aber auch schlicht um grobe Fahrlässigkeit! Wenn ein Server betroffen war, kann nämlich nicht ausgeschlossen werden, dass dabei sein privater Schlüssel abhanden gekommen ist. Ist dieser abhanden gekommen und wurde nach Einspielung des Bugfix nicht erneuert, könnte der an irgendeinem Netzknoten mitgeschnittene SSL-Traffic dem Belauscher dank des geklauten Schlüssels in nahezu Echtzeit die Passwort-Änderung im Klartext auf dem Silbertablett servieren.

Also, Ruhe bewahren und zuerst das SSL-Zertifikat der Seite überprüfen, auf der Ihr Euer Passwort ändern sollt/wollt. Nur dann das Passwort ändern, wenn die Lücke bereits geschlossen und das Zertifikat am 08.04.2014 bzw. später ausgestellt wurde. Ist es nicht der Fall, und Ihr ändert Euer Passwort daraufhin nicht, können Eure ggf. vor dem Heartbleed-Alarm mitgeschnittenen Zugangsdaten zwar missbraucht werden, aber andereseits ist ein aktueller Mitschnitt und das fogliche Abhandenkommen der geänderten Passwörter bei einem alten Zertifikat viel wahrscheinlicher, weil es sich jetzt bei den dilettantischen Passwort-Änderungsempfehlungen ja erst richtig lohnt, die Leitungen anzuzapfen – die Ausbeute wird um ein vielfaches höher sein als sich Geheimdienste oder Kriminelle je erträumt hätten. :hammer:

[samm]

Willkommener Anlass, Open Source zu bashen? Was gefehlt hat, war ein Audit, ansonsten *shrug* Ausserdem könnte man in die Source kucken, und wie beim Apple SSL-Bug plausibilisieren, ob es wirklich nur ein Bug war.

Anyway, das gibt einiges upzudaten *seufz* Gut ist die Infrastruktur @Arbeit nicht betroffen.

[Crushinator]

Willkommener Anlass, Open Source zu bashen? Was gefehlt hat, war ein Audit, ansonsten *shrug* Ausserdem könnte man in die Source kucken, und wie beim Apple SSL-Bug plausibilisieren, ob es wirklich nur ein Bug war. [...]

Ich verbringe seit Dienstagmorgen 80% meiner Zeit mit Heartbleed-Analyse und bin wie einige andere (http://blog.fefe.de/?ts=adba343f) zu dem Schluss gekommen, dass es sich mit hoher Wahrscheinlichkeit eher um ein Backdoor handelt, das als Trivial-Bug zu tarnen versucht wird. Kein C-Entwickler, schon gar kein Doktorand mit viel beigesteuertem Code verlässt sich darauf, dass von außen über Sockets eingereichte Daten immer so aussehen, wie man sie erwartet. :upara:

[samm]

Mmmmh, lecker, danke für die Infos :) Henson - der Auditor von damals - ist auch derzeit fleissig am committen. Zeit für Alternativen? Wird nächste Woche auf der regulären Arbeit sicher auch wichtiges Thema sein... Als ob wir Zeit dafür hätten, gnaaah!

[foobi]

Einige in der Liste aufgeführte Dienste haben ihre SSL-Zertifikate noch gar nicht erneuert (z.B. T-online) und empfehlen ihren Nutzern trotzdem, sie sollen ihre Passwörter ändern! WTF?!
Um prüfen zu können ob ein Zertifikat in den letzten Tagen ausgetauscht wurde, benötigt man als Außenstehender den Fingerabdruck oder Modulus des Zertifikats von heute und die selbe Information von letzter Woche (oder früher). Gibt es ein Archiv, ein Browserplugin oder einen Webdienst der solche Fingerabdrücke aus der Vergangenheit sammelt und wo man das abrufen könnte?

IMHO handelt es sich dabei entweder um irrtümlich als solche verstandene Empfehlungen, oder um eine um die Hälfte der Aussage gekürzte Wiedergabe der Empfehlung, oder aber auch schlicht um grobe Fahrlässigkeit! Wenn ein Server betroffen war, kann nämlich nicht ausgeschlossen werden, dass dabei sein privater Schlüssel abhanden gekommen ist. Ist dieser abhanden gekommen und wurde nach Einspielung des Bugfix nicht erneuert, könnte der an irgendeinem Netzknoten mitgeschnittene SSL-Traffic dem Belauscher dank des geklauten Schlüssels in nahezu Echtzeit die Passwort-Änderung im Klartext auf dem Silbertablett servieren.
Jain, dazu wäre immer noch ein Man-in-the-middle-Angriff notwendig, das heißt der Angreifer müsste den Datenverkehr zwischen Server und allen Clients über sein System umleiten können (oder zumindest den Verkehr zwischen Server und meinem Client). Das ist zwar einfacher machbar als einen SSL-Datenstrom zu knacken, aber hat nicht ganz Silbertablett-Niveau.

Ich empfehle folgendes:

Wenn ein Dienst von der OpenSSL-Lücke betroffen ist, dann diesen Dienst solange nicht nutzen bis die Lücke geschlossen wurde. Die Verwundbarkeit kann man mit Programmen auf seinem eigenen PC, oder mit Online-Dienste wie http://filippo.io/Heartbleed/* und http://possible.lv/tools/hb/ testen.

Wenn 1. geklappt hat, ist man nun fertig. Falls man den betroffenen Dienst in den letzten Tagen doch nutzte, geht es weiter mit Schritt 2.

Warten bis die Lücke geschlossen wurde und so schnell wie möglich sein Passwort ändern, unabhängig davon ob das Zertifikat ausgetauscht wurde oder nicht. Weil: Die Lücke erlaubt ja das Auslesen zufälliger Daten im Speicher. Es kann sein, dass ein Angreifer zwar nicht den privaten Schlüssel des Servers, dafür aber meine Benutzerdaten erhalten hat.
Beim Anmelden schickt man seine Benutzerdaten zwar nochmals über die Leitung (was bei einem potentiellen Man-in-the-middle-Angriff schlecht wäre), ich halte dies aber trotzdem für die bessere Variante als mit einem möglicherweise kompromitierten Passwort weiterzuleben. Denn das Durchführen eines Man-in-the-middle-Angriffs ist deutlich schwieriger und viel weniger Leuten möglich, als das vorherige Ausnutzen der OpenSSL-Lücke. Das heißt die Wahrscheinlichkeit, dass
a) jemand mein kurzes Passwort aus dem Serverspeicher auslesen konnte ist deutlich höher, als
b) dass jemand den sehr langen privaten Zertifikatschlüssel auslesen konnte und einen Man-in-the-middle-Angriff gegen mich durchzuführen in der Lage ist.

Falls bei Schritt 2 das Zertifikat noch nicht ausgetauscht war, dann warten bis es ausgetauscht wurde und anschließend das Passwort ein zweites Mal ändern.


Also, Ruhe bewahren und zuerst das SSL-Zertifikat der Seite überprüfen, auf der Ihr Euer Passwort ändern sollt/wollt. Nur dann das Passwort ändern, wenn die Lücke bereits geschlossen und das Zertifikat am 08.04.2014 bzw. später ausgestellt wurde.
Wann ein Zertifikat ausgestellt wurde, lässt sich leider nicht so einfach feststellen. Das Valid-from-Datum im Zertifikats lässt keine Rückschlüsse darauf zu, wann das Zertifikat erstellt wurde, sondern besagt nur ab wann es gültig ist.
Tatsächlich ist es so, dass viele Zertifikatsanbieter im Zuge der OpenSSL-Lücke einen kostenlosen Umtausch des Zertifikats anbieten. Dabei wird dem Kunden aber natürlich nicht zusätzliche Laufzeit geschenkt. Entweder der Anbieter kürzt daher die Zertifikatslaufzeit, oder er druckt in das neue Zertifikat einfach die selben Valid-From- und Valid-To-Zeitstempel des ursprünglichen Zertifikats rein. Dann ändert sich an den Datumsangaben nichts, aber das Zertifikat ist trotzdem ein neues.

[Crushinator]

Um prüfen zu können ob ein Zertifikat in den letzten Tagen ausgetauscht wurde, benötigt man als Außenstehender den Fingerabdruck oder Modulus des Zertifikats von heute und die selbe Information von letzter Woche (oder früher). Gibt es ein Archiv, ein Browserplugin oder einen Webdienst der solche Fingerabdrücke aus der Vergangenheit sammelt und wo man das abrufen könnte?

Ich klicke dafür auf das Schlösschen-Symbol im Browser und lasse mir mit "Zertifikat anzeigen" (den Knopf in den Tabs/Untermenüs des aufgehenden Dialogs suchen und betätigen) und es verrät mir das:

http://abload.de/img/cert_telekomy8ux8.png

Damit weiß ich anhand des Gültigkeitsdatums sofort, dass es kein neues ist.

Die Vorraussetung für ein Ersatz-Zertifikat für einen kompromittierten Schlüssel ist sinnvollerweise zwingend, dass der alte revoked und ein neuer öffentlicher Schlüssel samt CSR eingereicht wird. Und der Ersatz wird wie sonst auch nach einem Revoke mit Gültigkeit ab dem Zeitpunkt der Signierung durch die CA erstellt, u.A. weil es schlicht keinen allgemeinen Sinn ergibt, eine Gültigkeit in der Vergangenheit zu erzeugen. Das "Verfalldatum" kann aber bei einem kostenlosen Ersatz durchaus dem des widerrufenen entsprechen.


Jain, dazu wäre immer noch ein Man-in-the-middle-Angriff notwendig, das heißt der Angreifer müsste den Datenverkehr zwischen Server und allen Clients über sein System umleiten können (oder zumindest den Verkehr zwischen Server und meinem Client). Das ist zwar einfacher machbar als einen SSL-Datenstrom zu knacken, aber hat nicht ganz Silbertablett-Niveau.

Bei Fragen zu "Leitung anzapfen" lesen Sie das "Gesetz zur Beschränkung des Brief-, Post- und Fernmeldegeheimnisses. (Gesetz zu Artikel 10 Grundgesetz) (G 10)" oder schlagen Sie Ihren WLAN-Hotspot-Betreiber. :usweet:

Ich empfehle folgendes:

Wenn ein Dienst von der OpenSSL-Lücke betroffen ist, dann diesen Dienst solange nicht nutzen bis die Lücke geschlossen wurde. Die Verwundbarkeit kann man mit Programmen auf seinem eigenen PC, oder mit Online-Dienste wie http://filippo.io/Heartbleed/* und http://possible.lv/tools/hb/ testen.

Wenn 1. geklappt hat, ist man nun fertig. Falls man den betroffenen Dienst in den letzten Tagen doch nutzte, geht es weiter mit Schritt 2.

Warten bis die Lücke geschlossen wurde und so schnell wie möglich sein Passwort ändern, unabhängig davon ob das Zertifikat ausgetauscht wurde oder nicht. Weil: Die Lücke erlaubt ja das Auslesen zufälliger Daten im Speicher. Es kann sein, dass ein Angreifer zwar nicht den privaten Schlüssel des Servers, dafür aber meine Benutzerdaten erhalten hat.
Beim Anmelden schickt man seine Benutzerdaten zwar nochmals über die Leitung (was bei einem potentiellen Man-in-the-middle-Angriff schlecht wäre), ich halte dies aber trotzdem für die bessere Variante als mit einem möglicherweise kompromitierten Passwort weiterzuleben. Denn das Durchführen eines Man-in-the-middle-Angriffs ist deutlich schwieriger und viel weniger Leuten möglich, als das vorherige Ausnutzen der OpenSSL-Lücke. Das heißt die Wahrscheinlichkeit, dass
a) jemand mein kurzes Passwort aus dem Serverspeicher auslesen konnte ist deutlich höher, als
b) dass jemand den sehr langen privaten Zertifikatschlüssel auslesen konnte und einen Man-in-the-middle-Angriff gegen mich durchzuführen in der Lage ist.

Falls bei Schritt 2 das Zertifikat noch nicht ausgetauscht war, dann warten bis es ausgetauscht wurde und anschließend das Passwort ein zweites Mal ändern.



Ja, das kann man natürlich so machen. Man darf nur nicht vergessen, das Passwort auf jeden Fall ein zweites mal zu ändern, sobald das Zertifikat erneuert wurde. Aber wie gesagt, ich halte es gerade im Hinblick auf die WLAN-Hotspot-Problematik (scheunentoroffenes WLAN ftw) für wahrscheinlicher, dass momentan viele Kriminielle im Besitz der erbeuteten Schlüssel großer Sites dabei sind, jeglichen Datenverkehr in öffentlichen Hotspots aufzuzeichnen, in der Hoffnung, dabei möglichst viele Android <= 2.3.x Devices zu erwischen, die von Haus aus kein Perfect Forward Secrecy beherrschen, damit sie später bei geringstem Aufwand all die neuen Passwörter aus den entschlüsselten Datenpaketen extrahieren können. ;D

Letztendlich hoffe ich für mich selbst, dass meine Zugangsdaten zu den betroffenen Diensten, wenn, nur von Geheimdiensten erbeutet wurden.


Wann ein Zertifikat ausgestellt wurde, lässt sich leider nicht so einfach feststellen. Das Valid-from-Datum im Zertifikats lässt keine Rückschlüsse darauf zu, wann das Zertifikat erstellt wurde, sondern besagt nur ab wann es gültig ist.
Tatsächlich ist es so, dass viele Zertifikatsanbieter im Zuge der OpenSSL-Lücke einen kostenlosen Umtausch des Zertifikats anbieten. Dabei wird dem Kunden aber natürlich nicht zusätzliche Laufzeit geschenkt. Entweder der Anbieter kürzt daher die Zertifikatslaufzeit, oder er druckt in das neue Zertifikat einfach die selben Valid-From- und Valid-To-Zeitstempel des ursprünglichen Zertifikats rein. Dann ändert sich an den Datumsangaben nichts, aber das Zertifikat ist trotzdem ein neues.

Die selben Valid-From- und Valid-To-Zeitstempel des ursprünglichen Zertifikats reinzuhauen ist AFAIK nicht ohne weiteres möglich, ratsam erst recht nicht.

[Birdman]

Damit weiß ich anhand des Gültigkeitsdatums sofort, dass es kein neues ist.

Das ist vollkommen untauglich für den aktuellen Fall.
Das Start/End Datum bleibt bei neu ausgestellten (re-issue) Zertifikaten genau gleich, da kann man nur über den Thumbprint vergleichen.

Maximal einer bei dem das alte Cert eh in den nächsten Tagen ausläuft wird hier direkt ein vollkommen neues Zertifikat beantragen und installieren. (Und da ändern sich dann auch die Timestamps)

[Crushinator]

Das ist vollkommen untauglich für den aktuellen Fall.
Das Start/End Datum bleibt bei neu ausgestellten (re-issue) Zertifikaten genau gleich, da kann man nur über den Thumbprint vergleichen. [...]

Sorry, aber dann hätte der Serverbetreiber eine Lösung gefunden, die am Problem ziemlich vorbeigeht. Ein "re-issue" ist nicht dazu gedacht, kompromittierte Zertifikate wie im aktuellen Fall zu ersetzen, sondern nur (durch HDD-Crash etc.) verlorengegangene. Dabei wird das alte Zertifikat nicht widerrufen! Aus Security Sicht ist letzteres aber bei Heartbleed grob fahrlässig und dazu hirnrissig, weil kein Mensch ernsthaft will, dass sich ein krimineller Server glaubwürdig für seinen ausgeben kann, weil die CA das kompromittierte Zertifikat nicht auf die Revocation list des OCSP gesetzt hat.

[Edit]
Langsam versteh ich, warum Bruce Schneier das Ganze "auf einer Katastrophenskala von 1 bis 10, eine 11" nennt. Nicht nur das Ausmaß ist katastrophal, viele Schlussfolgerungen sind es offensichtlich auch.

[Annator]

Hat mal einer ein Beispiel was in diesen 8kB zuviel gesendeten drin steht bei so einem angriff? Ich kann mir irgendwie nicht vorstellen sinnvolle Informationen aus einem zufälligen Speicherbereich zu bekommen.

[Birdman]

Sorry, aber dann hätte der Serverbetreiber eine Lösung gefunden, die am Problem ziemlich vorbeigeht. Ein "re-issue" ist nicht dazu gedacht, kompromittierte Zertifikate wie im aktuellen Fall zu ersetzen, sondern nur (durch HDD-Crash etc.) verlorengegangene. Dabei wird das alte Zertifikat nicht widerrufen! Aus Security Sicht ist letzteres aber bei Heartbleed grob fahrlässig und dazu hirnrissig, weil kein Mensch ernsthaft will, dass sich ein krimineller Server glaubwürdig für seinen ausgeben kann, weil die CA das kompromittierte Zertifikat nicht auf die Revocation list des OCSP gesetzt hat.

?!?!?
Klar ist ein re-issue dazu gedacht und nein es macht auch KEINEN Sinn jetzt noch einen andern Mechanismus zu erfinden der ein neues Cert ausstellt und gleichzeitig/automatisch das alte revoked....

Das soll und darf man bitte noch selber machen, denn sonst ist ein Server mitunter für mehrere Stunden/Tage "offline" - und zwar die Zeit die man selber braucht um das neue Zertifikat per Email zu empangen, auf dem/den Servern zu installieren und die Services neu zu starten.

Daher ist das korrekte vorgehen durchaus dass man sich das Cert re-issuen lässt (mit einem CSR der auf einem neuen Key basiert), dieses auf den Systemen installiert und anschliessend erst das alte auf die RevocationList setzen lässt.

[AnarchX]

Hat mal einer ein Beispiel was in diesen 8kB zuviel gesendeten drin steht bei so einem angriff? Ich kann mir irgendwie nicht vorstellen sinnvolle Informationen aus einem zufälligen Speicherbereich zu bekommen.

Es gibt genug Beispiele, in denen Nutzernamen/E-Mail-Adressen - Passwort-Kombinationen in diesem Speicherbereich waren.

[Annator]

Es gibt genug Beispiele, in denen Nutzernamen/E-Mail-Adressen - Passwort-Kombinationen in diesem Speicherbereich waren.

Name und Passwort? Ok das ist wirklich heftig.

[Birdman]

Hat mal einer ein Beispiel was in diesen 8kB zuviel gesendeten drin steht bei so einem angriff? Ich kann mir irgendwie nicht vorstellen sinnvolle Informationen aus einem zufälligen Speicherbereich zu bekommen.
Hier z.B. was bei meinem ESXi 5.5 TestSystem zurückkommt:


Connecting...
Sending Client Hello...
Waiting for Server Hello...
... received message: type = 22, ver = 0302, length = 54
... received message: type = 22, ver = 0302, length = 1015
... received message: type = 22, ver = 0302, length = 4
Sending heartbeat request...
... received message: type = 24, ver = 0302, length = 16384
Received heartbeat response:
.@....SC[...r...
.+..H...9.......
.w.3....f.....".
!.9.8.........5.
................
............3.2.
....E.D...../...
A...............
................
..I...........4.
2...............
................
................
....#....... xml
ns:xsi="http://w
ww.w3.org/2001/X
MLSchema-instanc
e">.<soapenv:Bod
y>.<WaitForUpdat
es xmlns="urn:vp
xa3"><_this type
="PropertyCollec
tor">propertyCol
lector</_this><v
ersion>2064</ver
sion></WaitForUp
dates>.</soapenv
:Body>.</soapenv
:Envelope>..e...
3.yk........3...
392e9</operation
ID>.</soapenv:He
ader>.<soapenv:B
ody>.<CreateFilt
er xmlns="urn:vp
xa3"><_this type
="PropertyCollec
tor">propertyCol
lector</_this><s
pec><propSet><ty
pe>Task</type><p
athSet>info</pat
hSet></propSet><
objectSet><obj t
ype="Task">sessi
on[b4fd67fd-4f0e
-72ef-c6b7-d9705
bf47dee]52b42aaf
-fddc-433f-9e95-
19f9a240e3c2</ob
j></objectSet></
spec><partialUpd
ates>true</parti
alUpdates></Crea
teFilter>.</soap
env:Body>.</soap
env:Envelope>.UP
...7P.... ywa...
y...............
<param2 xsi:type
="xsd:string">mo
dify</param2></I
nvokeHostNetwork
TransactionCall>
.</soapenv:Body>
.</soapenv:Envel
ope>a7L.......>^
}K..............
se</checkBeacon>
</failureCriteri
a><nicOrder><act
iveNic>vmnic0</a
ctiveNic><active
Nic>vmnic1</acti
veNic></nicOrder
></nicTeaming><o
ffloadPolicy></o
ffloadPolicy><sh
apingPolicy></sh
apingPolicy></po
licy></param2></
InvokeHostNetwor
kTransactionCall
>.</soapenv:Body
>.</soapenv:Enve
lope>..W`.<i....
.....A.~........
Speed>minimum</c
heckSpeed><speed
>10</speed><chec
kDuplex>false</c
heckDuplex><full
Duplex>false</fu
llDuplex><checkE
rrorPercent>fals
e</checkErrorPer
cent><percentage
>0</percentage><
checkBeacon>fals
e</checkBeacon><
/failureCriteria
><nicOrder><acti
veNic>vmnic0</ac
tiveNic></nicOrd
er></nicTeaming>
<offloadPolicy><
csumOffload>true
</csumOffload><t
cpSegmentation>t
rue</tcpSegmenta
tion><zeroCopyXm
it>true</zeroCop
yXmit></offloadP
olicy><shapingPo
licy><enabled>fa
lse</enabled></s
hapingPolicy></p
olicy><mtu>1500<
/mtu></param2></
InvokeHostNetwor
kTransactionCall
>.</soapenv:Body
>.</soapenv:Enve
lope>.FV.-i...nt
..w.............
><counterId>183<
/counterId><inst
ance></instance>
</mid><mid><coun
terId>263</count
erId><instance><
/instance></mid>
<mid><counterId>
264</counterId><
...

[Ganon]

Hat mal einer ein Beispiel was in diesen 8kB zuviel gesendeten drin steht bei so einem angriff? Ich kann mir irgendwie nicht vorstellen sinnvolle Informationen aus einem zufälligen Speicherbereich zu bekommen.

Büddeschön:
https://www.mattslifebytes.com/?p=533

passend dazu:
http://xkcd.com/1354/

[Crushinator]

?!?!?
[...] Daher ist das korrekte vorgehen durchaus dass man sich das Cert re-issuen lässt (mit einem CSR der auf einem neuen Key basiert), dieses auf den Systemen installiert und anschliessend erst das alte auf die RevocationList setzen lässt.

Das wäre höchstens eine Lösung für automatisierte Massenabfertigungen, aber keine geeignete, um den SSL-Client bzw. den User hinreichend über die Schlüsselerneuerung zu informieren. Aber okay, immerhin wäre der aktuelle SSL-Verkehr geschützt – I got your point.

[Edit]
Guckt mal, so macht man es, wenn man seine User bestens schützen will: https://posteo.de/blog/heartbleed-bug-bitte-%C3%A4ndern-sie-ihr-passwort

[Birdman]

Nein, Benachrichtigung für den User ist nicht vorgesehen.

"Eigentlich" müssten Browser schon lange eine Funktion haben, welche beim Wechsel eines Zertifikates/Thumbprint von einer bereits bekannten/besuchten Seite eine Meldung ausspucken, ganz unabhängig von Heartbleed.
Sowas würde auch mitm Attacken für den Enduser sichbar machen, aber hätte natürlich wieder lästige popUps zur Folge....


Btw. hab grad gesehen dass die Datumsgeschichte je nach CA wieder anders gehandhabt wird.
Es gibts anscheinend durchaus auch solte (z.B. Geotrust), welche das Startdatum bei Re-Issues neu setzen, was für den aktuellen Fall sehr praktisch ist.

[Crushinator]

[...] Btw. hab grad gesehen dass die Datumsgeschichte je nach CA wieder anders gehandhabt wird.
Es gibts anscheinend durchaus auch solte (z.B. Geotrust), welche das Startdatum bei Re-Issues neu setzen, was für den aktuellen Fall sehr praktisch ist.

Ich habe überhaupt keine praktische Erfahrung mit CAs, die "re-issue" über das Interface anbieten. Meine kennen nur "Neues Zertifikat" und Revoke. ^^

[Birdman]

Ich habe überhaupt keine praktische Erfahrung mit CAs, die "re-issue" über das Interface anbieten. Meine kennen nur "Neues Zertifikat" und Revoke. ^^
"Neues Zertifikat" im Sinne von wirklich NEU, aka Laufzeit verlängern und damit auch mit Kostenfolgen verbunden?

[Crushinator]

"Neues Zertifikat" im Sinne von wirklich NEU, aka Laufzeit verlängern und damit auch mit Kostenfolgen verbunden?

Richtig, und unterschiedliche Kostenfolgen: mal ein Auge zudrücken wegen Heartbleed, und mal die strikte Policy à la StartCom.

[Birdman]

Pft, soweit kommts noch dass ich da Geld rüberwachsen lasse für einen Case wo mich keine Schuld trifft dass der Key nicht mehr als vetrauenswürdig angeschaut werden kann...

Der Scheiss kostet mich schon genug Zeit und Nerven....

[Milton]

http://imgs.xkcd.com/comics/heartbleed_explanation.png

EDIT: Ooops, wurde ja schon verlinkt.

Weiss jemand ob man ein Risiko hat, wenn der Router (DDWRT oder Tomato) eine OpenSSL Funktion hat? Ich weiss ehrlich gesagt gar nicht warum mein Router OpenSSL hat. Stellt das ein Risiko dar?

[Crushinator]

Weiss jemand ob man ein Risiko hat, wenn der Router (DDWRT oder Tomato) eine OpenSSL Funktion hat? Ich weiss ehrlich gesagt gar nicht warum mein Router OpenSSL hat. Stellt das ein Risiko dar?

http://dd-wrt.com/site/content/heartbleed-dd-wrtdd-wrt-online-services


[...]
In DD-WRT itself the following services are using OpenSSL with TLS:

openvpn
squid
freeradius
asterisk
curl
pound
tor
transmission

OpenSSL was updated immediately in the DD-WRT SVN repository. It can take a view days until we can provide updated versions for all routers. User running critical applications can contact us via the info mail form - but please check first if your setup is really affected by Heartbleed.


Wenn Du freeradius, OpenVPN, Tor oder asterisk (Telefonanlage) auf dem Router betreibst, der eine verwundbare OpenSSL-Version mitbringt, mögest Du Dich besonders alarmiert fühlen. Setzt Du nichts aus der Liste ein, kannst Du zur Gemütlichkeit übergehen. ^^

[Edit]
Wie man herausfindet, ob OpenSSL auf dem eigenen DD-WRT-Router betroffen ist: per Kommandozeile, ob nun per ssh oder telnet auf dem router eingeloggt oder über die GUI-Funktion: Administration -> Commands

find / -name libssl.so.*

ausführen lassen.

Spuckt sie /usr/lib/libssl.so.0.9.* aus -> Glück gehabt.

... wenn jedoch /usr/lib/libssl.so.1.0.0 -> sollte man noch mit

strings /usr/lib/libssl.so.1.0.0 | grep OpenSSL

herausfinden, welche.

Um es kurz zu machen: Das letzte Kommando könnt Ihr Euch z.Z. eigentlich ersparen, da Versionen nach 29.04.2012 eigentlich alle betroffen sind.

[Milton]

Wenn Du freeradius, OpenVPN, Tor oder asterisk (Telefonanlage) auf dem Router betreibst, der eine verwundbare OpenSSL-Version mitbringt, mögest Du Dich besonders alarmiert fühlen. Setzt Du nichts aus der Liste ein, kannst Du zur Gemütlichkeit übergehen. ^^

Danke! Gemuetlichkeit rocks!

[Disconnected]

Das wichtigste ist das Passwort für den primären E-Mail-Account, denn dieser ist quasi der Masterkey für alle übrigen Dienste.

[sei laut]

Das wichtigste ist das Passwort für den primären E-Mail-Account, denn dieser ist quasi der Masterkey für alle übrigen Dienste.
Relativ sicher ist in dem Zusammenhang nur ein Alias auf die eigentliche E-Mail Adresse. Dann muss man sich über sowas keine Gedanken machen, sofern kein Zusammenhang zwischen E-Mail Weiterleitung und eigentlichem Konto hergestellt werden kann. Denn ein Angreifer müsste erst mal rausfinden, wohin die Mails dann gehen.

[Disconnected]

Jaein, wenn man einmal die Zugangsdaten hat, hat man auch die Alias-Adresse. Und wenn die Mails nicht nach dem Abholen gelöscht werden zusätzlich noch eine Historie und Auskunft über sonstige Accounts.

[sei laut]

Wer sagt, dass sich Alias und Konto auf dem gleichen Server befinden? ;D
Schon klar, zuviel Aufwand für den Normalo, nur ist das ein leichtes Mittel mit Wirkung.
Wenn du so anfängst zu denken, kann man gleich den Internetstecker ziehen.

Das Problem ist ja wie immer nicht die eine Lücke, die gefunden wurde und die nun alle kennen, sondern die anderen 1000, die jemand gefunden hat und die sonst niemand kennt.

[PatkIllA]

Das letzte Kommando könnt Ihr Euch z.Z. eigentlich ersparen, da Versionen nach 29.04.2012 eigentlich alle betroffen sind.Der bei meinen Eltern ist auch betroffen.
Und hängt mit SSH im Netz (anderer Port und nur mit Zertifikat)

Die neueste Version die ich finden kann ist aber 2 Wochen alt.

[Disconnected]

Wer sagt, dass sich Alias und Konto auf dem gleichen Server befinden? ;D
Schon klar, zuviel Aufwand für den Normalo, nur ist das ein leichtes Mittel mit Wirkung.
Wenn du so anfängst zu denken, kann man gleich den Internetstecker ziehen.

Das Problem ist ja wie immer nicht die eine Lücke, die gefunden wurde und die nun alle kennen, sondern die anderen 1000, die jemand gefunden hat und die sonst niemand kennt.

Ich weiß ja nicht, von was für einer Konstellation Du da redest, aber für mich ist ein Alias einfach eine zusätzliche Adresse zu einem bestehenden E-Mail-Konto.

[foobi]

Ich klicke dafür auf das Schlösschen-Symbol im Browser und lasse mir mit "Zertifikat anzeigen" (den Knopf in den Tabs/Untermenüs des aufgehenden Dialogs suchen und betätigen) und es verrät mir das:

http://abload.de/img/cert_telekomy8ux8.png

Damit weiß ich anhand des Gültigkeitsdatums sofort, dass es kein neues ist.
Gerade das weiß man nicht. Das Startdatum eines Zertifikats ist nicht das selbe wie das Ausstelldatum (letzteres ist im Zertifikat nicht vorgesehen).

Nahezu alle CAs bieten momentan zB an kostenlos Zertifikate umzutauschen. Der Kunde wendet sich an seine CA: "Hey ich hab im Herbst ein Zertifikat bei euch erworben, Bestellnr 12345. Leider wurde es nun aufgrund der OpenSSL-Lücke möglicherweise kompromitiert. Daher hier mein neuer Request, bitte unterschreiben und das alte Zertifikat widerrufen". Die CA schaut dann in die Bestellung 12345, stempelt die selben Daten nochmal in den neuen Request (sozusagen einmal F5 drücken) und gibt dem Kunden das neue Zertifikat.
Kaufmännisch ist das weiterhin der selbe Artikel, technisch aber ein neues Zertifikat, da es von einem anderen Request mit anderem privaten Schlüssel abstammt.
Der Certificate Signing Request enthält ohnehin nie ein Start- oder Enddatum. Dieses wird immer erst durch die Zertifizierungsstelle (CA) eingetragen. Und ob die dort das heutige Datum oder ein anderes reinschreiben ist technisch gesehen egal, das sind alles nur Ziffern.

Hat mal einer ein Beispiel was in diesen 8kB zuviel gesendeten drin steht bei so einem angriff? Ich kann mir irgendwie nicht vorstellen sinnvolle Informationen aus einem zufälligen Speicherbereich zu bekommen.Es sind nicht 8 sondern 64KB, und man kann den Angriff beliebig oft durchführen, um immer neue zufällige Daten aus dem Speicher zu erhalten. Die Wahrscheinlichkeit, dass man dabei irgendwelche Passwörter, Session-IDs, private Schlüssel oder sonstwelche sensiblen Daten erwischt ist nicht besonders niedrig.
Das was seit Montag läuft sind keine gezielten Angriffe auf Nutzer X, sondern wildes Herumfischen um alles mögliche in die Finger zu bekommen. Leider wissen die Betroffenen hinterher nicht, ob und wen es erwischt hat, daher muss man um auf der sicheren Seite zu sein pauschal davon ausgehen, dass alle Systeme betroffen sind, die verwundbar waren.


Der bei meinen Eltern ist auch betroffen.
Und hängt mit SSH im Netz (anderer Port und nur mit Zertifikat)
SSH hat mit diesem Loch ja nichts zu tun.

[sei laut]

Ich weiß ja nicht, von was für einer Konstellation Du da redest, aber für mich ist ein Alias einfach eine zusätzliche Adresse zu einem bestehenden E-Mail-Konto.
Genau. Und du hast keine Ahnung, wo das Konto ist, wenn die Mail an hülülü@blubb.de geht, sofern du nicht den blubb.de Mailserver knackst.
Man kann ja Mails umleiten, wie man lustig ist. :D

[ENKORE]

Hat mal einer ein Beispiel was in diesen 8kB zuviel gesendeten drin steht bei so einem angriff? Ich kann mir irgendwie nicht vorstellen sinnvolle Informationen aus einem zufälligen Speicherbereich zu bekommen.

Der Witz ist, dass der Speicherbereich keinesfalls zufällig ist, weil OpenSSL seinen eigenen Allocator benutzt um Sicherheitsprüfungen (und damit Geschwindigkeitsverluste) bei einigen BSDs, bekommst du immer einen astreinen 64 KB Block gefüllt mit Daten von OpenSSL. Würde OpenSSL den normalen Allocator benutzen, würde man deutlich weniger bis fast nie seltener relevante Daten zurückbekommen — und den Serverprozess meistens crashen, was wiederrum die verfügbare Bandbreite für den Exploit reduziert (Serverinstanzen brauchen Zeit um neu hochzukommen und sind endlich, da die Chancen sehr hoch sind den Prozess zu crashen, kann man nicht etliche hunderttausende Angriffe / Sekunde fahren um relevante Daten abzufischen).

Aber so... richtig fett ins Knie geschossen mit dieser "Optimierung". Eh ne blöde Idee bei so einer kritischen Anwendung secrets quasi an einem Ort zu akkumulieren...

[Disconnected]

Genau. Und du hast keine Ahnung, wo das Konto ist, wenn die Mail an hülülü@blubb.de geht, sofern du nicht den blubb.de Mailserver knackst.
Man kann ja Mails umleiten, wie man lustig ist. :D
OK, eine Weiterleitung ist auch möglich. Spekulierst Du dann darauf, dass wenn der "äußere" Account kompromittiert ist, der "innere" nicht betroffen ist? Nutzt halt nichts, wenn es den "inneren" erwischt. Scheint mir eher so eine Art Vermeidung eines "Single point of impact" zu sein, oder?

[Lord Wotan]

Ich habe eine gute und eine schlechte Nachricht. Zuerst die gute: Das 3DC-Forum ist nicht betroffen; wir nutzen die anfällige OpenSSL-Version nicht. In other words: Security by mehr oder weniger zufälliger Update-Faulheit! (y)

Nun die schlechte ...



Einige in der Liste aufgeführte Dienste haben ihre SSL-Zertifikate noch gar nicht erneuert (wenn ich es korrekt erkenne, z.B. T-online) und empfehlen ihren Nutzern trotzdem, sie sollen ihre Passwörter ändern! WTF?! :eek:


Du sagst das die Telekom betroffen ist. Auf der Startseite hier steht aber das die Telekom nicht betroffen ist.

Und bei diesen Test wird alles als OK gezeigt.
http://filippo.io/Heartbleed/#kundencenter.telekom.de

[Lord Wotan]

Weiss jemand ob man ein Risiko hat, wenn der Router (DDWRT oder Tomato) eine OpenSSL Funktion hat? Ich weiss ehrlich gesagt gar nicht warum mein Router OpenSSL hat. Stellt das ein Risiko dar?
Fritz!Boxen sind nicht betroffen
http://www.avm.de/de/News/artikel/2014/open_ssl_fbox_nicht_betroffen.html?linkident=kurznotiert

[Thunder99]

Google hat noch nicht seine Zertifikate aktuallisiert, oder doch? (Ausgestellt ab 02.04.2014)

Facebook (1.3.14) auch nicht...

[Birdman]

Google hat noch nicht seine Zertifikate aktuallisiert, oder doch? (Ausgestellt ab 02.04.2014)
Facebook (1.3.14) auch nicht...
Das Datum hat keinerlei Relevanz, da nicht das Ausstell-Datum ersichtllich ist, sondern das Startdatum ab wann ein Cert gültig ist.

[Acid-Beatz]

Öhm, mein Facebook sagt mir auch, dass das Zertifikat seit 1.3.2014 gültig ist, sprich unsicher/kompromittiert sein kann, sehe ich das richtig?
Laut cnet (http://www.cnet.de/88128840/openssl-luecke-heartbleed-auf-welchen-webseiten-sollte-man-das-passwort-aendern/) aus dem Startposting ist die Lücke gepatched, Passwort ändern bringt aber nichts, sehe ich das gerade richtig?


Greez

Edit: Etwas zu langsam gewesen @Birdman: Welchen Sinn macht es, ein Zertifikat rück-zu-datieren :confused:

[Birdman]

Für den aktuellen Fall bringt es gar nicht, aber die meisten CA's nutzen hier halt die normale "re-issue" Abläufe welche auch verwendet werden wenn man z.B. von sich aus ein neues Cert braucht da man den alten Key verloren hat oder wenn man ein Cert auf mehreren Rechnern installieren will - z.b. bei Wildcard Certs (und hierbei will man meist nicht überall den selben Key verwenden)

In solchen Fällen macht es durchaus Sinn, dass die "original" Daten drin bleiben, so erkennt man auch für welche Laufzeit man ursprünglich ein Zertifikat gekauft hat. (nicht dass dies entscheidend wäre)

[Disconnected]

Welche CA macht denn re-issues? Wenn das Zertifikat abgelaufen ist, macht man erneut einen CSR und bekommt ein neues. Außerdem, warum sollte man verschiedene Keys für ein Wildcardzertifikat verwenden? Das ist ja gerade der Sinn dahinter, dass man sie für alle Hosts einer Domäne verwenden kann. Die sind nämlich viel teurer als normale.

[sei laut]

OK, eine Weiterleitung ist auch möglich. Spekulierst Du dann darauf, dass wenn der "äußere" Account kompromittiert ist, der "innere" nicht betroffen ist? Nutzt halt nichts, wenn es den "inneren" erwischt. Scheint mir eher so eine Art Vermeidung eines "Single point of impact" zu sein, oder?
a) Man könnte auch weiterleiten ohne Account, dazu braucht man aber einen eigenen Server
b) Man muss immer versuchen, vom Standardfall abzuweichen. In dem Moment, wo es 1-2 mehr Hürden gibt, verlieren Angreifer meist das Interesse, weil es immer leichtere Opfer gibt. ;)
Weiterleiten hat auch den Vorteil: Wird der weitergeleiitete Account zugespamt, nimmt man einfach einen neuen - die Freunde, bzw. vertrauenswürdige haben eh die "richtige" Adresse und man kann sowas dann beruhigt machen.

@Zertifikat: Opera zeigt beide Daten an, also Gültig ab und Gültig bis - gültig bis ist 2015.
Edit: Achso, geht darum, dass das Datum so "früh" ist - ihr könnt davon ausgehen, dass sowohl Google als auch Facebook zu denen gehörten, die vorab informiert wurden und daher früher an Patches kamen.

[Crushinator]

Einer der Entdecker der Lücke arbeitet bei Google. Man kann also davon ausgehen, dass sie die Lücke sehr früh bei sich selbst geschlossen haben.


This bug was independently discovered by a team of security engineers (Riku, Antti and Matti) at Codenomicon and Neel Mehta of Google Security, who first reported it to the OpenSSL team. Codenomicon team found heartbleed bug while improving the SafeGuard feature in Codenomicon's Defensics security testing tools and reported this bug to the NCSC-FI for vulnerability coordination and reporting to OpenSSL team.

[reallord]

Schön und gut, aber wie stelle ich als Enduser nun fest, ob ein Zertifikat erst erstellt wurde, nachdem Seite x die Lücke geschlossen hat.

Cert Fingerprint nutzt mir ohne Vergleichswert nix...

[Crushinator]

Schön und gut, aber wie stelle ich als Enduser nun fest, ob ein Zertifikat erst erstellt wurde, nachdem Seite x die Lücke geschlossen hat.

Cert Fingerprint nutzt mir ohne Vergleichswert nix...

Kurz und bündig: Das kannst Du als Enduser nicht zuverlässig feststellen. Selbst Facebooks Frontend-Server in DE haben noch nicht alle das neue Zertifikat. FB sagt zwar, sie hätten den Bug beseitigt und die Testseite von lastpass (https://lastpass.com/heartbleed/?h=www.facebook.com) bestätigt sogar das neue Zertifikat; aber das gilt nur für die Server, die lastpass.com von ihrem Standort aus als facebook.com sieht bzw. per DNS Loadbalancing zugewiesen bekommt – wahrscheinlich welche in US oder UK.

Wenn ich hier ein traceroute zu www.facebook.com mache, lande ich auf einem Server in Frankfurt, und der hat noch kein neues Zertifikat, und das wird auch so von der Testseite von lastpass für facebook.de (https://lastpass.com/heartbleed/?h=www.facebook.de) bestätigt.

Ich selbst habe jedenfalls beschlossen, nirgendwo mein Passwort einzugeben oder zu ändern, wenn ich kein neues Zertifikat erkennen kann.

[Acid-Beatz]

Wenn ich hier ein traceroute zu www.facebook.com mache, lande ich auf einem Server in Frankfurt
Mhm, ich lande mitten in Kansas :eek:


Greez

[Annator]

Hier kann man Seiten testen:

http://filippo.io/Heartbleed/

[rokko]

Was bedeutet das für mich und Millionen andere Daus?

[Crushinator]

Was bedeutet das für mich und Millionen andere Daus?
http://www.zeit.de/digital/datenschutz/2014-04/openssl-heartbleed-datensicherheit-passwort

[foobi]

Schön und gut, aber wie stelle ich als Enduser nun fest, ob ein Zertifikat erst erstellt wurde, nachdem Seite x die Lücke geschlossen hat.
Nachfragen. Viele große Anbieter haben aber auch schon von sich aus Mitteilungen veröffentlicht, ob sie betroffen waren oder nicht: http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/

Wenn einem das zu blöd ist, kann man seine Zugangsdaten auch einfach nur bei den wichtigsten Seiten ändern und den Rest auf sich beruhen lassen.

[samm]

Schön und gut, aber wie stelle ich als Enduser nun fest, ob ein Zertifikat erst erstellt wurde, nachdem Seite x die Lücke geschlossen hat.

Cert Fingerprint nutzt mir ohne Vergleichswert nix...Könntest immerhin mit dem prinzipiell super Addon "Perspectives" checken, seit wann ein Zertifikat von den Notaries gesehen wurde. Funktioniert leider nur auf FF: http://perspectives-project.org/

Beispiel GMX:
48479

[Acid-Beatz]

Guten Tag,
jetzt noch mal eine andere, dumme Frage von mir, die in diese Richtung geht, ich schieb`sie jetzt einfach mal hier ein:
Ich hab die 3d-center https Seite gebookmarked und gerade ist mir aufgefallen, dass mein Browser beim Anmelden kurz das https-Symbol/Schloss bringt (quasi ab Eingabe des Passworts bis zu dem Zeitpunkt "Herzlichen Glückwunsch Acid-Beatz, Sie sind angemeldet und werden weitergeleitet", danach verschwindet das Symbol wieder und ich bin unverschlüsselt unterwegs, wenn ich das gerade richtig interpretiere.
Soll das so sein oder ist hier was in die Hose gegangen?


Greez

Edit: Gerade noch mal nachgesehen: Dass Problem tritt bei Mozilla scheinbar nicht auf, der andere Browser war Safari (beide unter OS X)

[sei laut]

Foren und deren Nutzer binden Content unverschlüsselt ein, z.B. Bilder.
Wenn du auf einer Seite bist, wo genau das gemacht wird, sagt dein Browser folgerichtig, dass nicht die ganze Seite verschlüsselt ist (als Beispiel das Bild), aber anderes schon.
Da die Browser da nicht differenzieren, wird allgemein gewarnt und der Nutzer muss entscheiden, ob ok oder nicht.
Machen alle Browser so, wenn Firefox nicht meckert, hast du zufällig eine Seite ohne Fremdcontent aufgerufen.
(dass das Forum Anhänge ohne https einbindet, ist aber doof, sonst wäre die Seite hier ok)

@rokko: Nichts. Internetstecker ziehen. Als normaler Niutzer muss man davon ausgehen, dass alle Daten bekannt sein könnten, die bekannt werden hätten können. Das kann man aber einem solchen nicht zumuten, dass er alles ändert. Zudem.. die nächste Lücke kommt bestimmt.

[Acid-Beatz]

Mhm, bin mir gerade nicht so ganz sicher, ob du mich zu 100% verstanden hast:
Wenn ich zum Beispiel https://www.forum-3dcenter.org/vbulletin als Initialadresse nehme, dann bekomme ich einmal eine verschlüsselte Verbindung (Firefox) und einmal nicht (Safari).
Wenn ich mich bei diesem Punkt einlogge, dann baut Safari kurz (wie in meinem Posting darüber beschrieben) eine Verschlüsselte Verbindung auf, verlässt diese aber dann bei der Rückkehr ins Forum wieder - Firefox zeigt dieses Verhalten nicht, ich habe vom Seitenaufruf bis zum Verlassen eine verschlüsselte Verbindung ...


Greez

[sei laut]

Bei mir hat Firefox die unsicheren Inhalte automatisch geblockt. Bei dir wird das wohl nicht angezeigt oder du hast nicht auf das "Schild" geklickt.
Wenn du willst, können wir darüber per PN reden. Ist hier halt Offtopic.

[uweskw]

Ich nutze jetzt KeePass, ein Passwortsafe, Open Source
http://keepass.info/
macht zwar ein bisschen Mühe beim ersten mal einrichten, ist dann aber sehr bequem in der Anwendung (Autocomplete). Hab die Portable: Einmal auf dem Desktop, die gleiche auf nem USB-Stick zum mitnehmen und nochmal als eiserne Reserve hochgeladen.
Mir war gar nicht klar was da so zusammen kommt. Mit Pins und Logins für verschiedene Computer komm ich mittlerweile auf über 30 schützenswerte! Passwörter. Die ganzen unwichtigen Foren-Logs sind da noch nicht mal dabei.
Auf alle Fälle fühle ich mich jetzt mit vernünftigen Passwörten ne Ecke sicherer.

Greetz
U.S.

[schalala]

Hallo,
ich habe ein StartSSL Zertifikat und möchte es inkl. priv. Schlüssel austauschen.
Ist ein revoke notwendig wenn ich mir an einer anderen Stelle ein neues Zertifikat ausstellen lasse?

[Crushinator]

Hallo,
ich habe ein StartSSL Zertifikat und möchte es inkl. priv. Schlüssel austauschen.
Ist ein revoke notwendig wenn ich mir an einer anderen Stelle ein neues Zertifikat ausstellen lasse?

Es kommt auf die möglichen Folgen an, die es hätte, wenn Dein StartSSL-Zertifikat von einem fremden Server genutzt würde, um sich als Deiner auszugeben. Wenn Du diese Folgen als kritisch einstufst, ist ein Revoke auf jeden Fall ratsam.

[mekakic]

Wenn ich mir den fraglichen Code anschaue, dann ist das doch ein Bug, der eigentlich ein Klassiker für Valgrind und Co ist, oder übersehe ich etwas?

Ich weiß nicht was OpenSSL an QS fährt und wie ihre Testsuite aufgebaut ist, aber ich unterstelle einfach mal, dass OpenSSL solche Simulation und/oder ähnliches bei Releases (oder auch beim Nightly) durchläuft. Dass der Reviewer den Bug nicht gesehen hat... geschenkt, aber idR. müsste doch zumindest mal der Testplan reviewed worden sein und das Verhalten bei kaputten Nachrichtenpaketen beliebiger Permuation wäre doch einer der ersten Testfälle. So viele Felder hat die Heartbeat Extension ja auch nicht.

[Ganon]

Wenn ich mir den fraglichen Code anschaue, dann ist das doch ein Bug, der eigentlich ein Klassiker für Valgrind und Co ist, oder übersehe ich etwas?

Das ist kein normales malloc, was da passiert. Der Speicher hinter den Array-Grenzen ist komplett valide. OpenSSL holt sich halt den Speicher vom OS in größeren Blöcken und arbeitet darauf selbstständig (ähnlich wie Java oder Ruby). Hat halt nur keinen eigenen Bound-Check. Der Grund ist eine reine Performance-Entscheidung. Damit hebelt man natürlich einige andere Sicherheitsfeatures schon direkt da aus,

[Coda]

Das Problem ist, dass es nichtmal gängige SCA tools gesehen haben, so bescheuertes C-Gehacke ist das. Geht mir auf die Nerven, wenn ich so Code seh! Amateurpack.

[Gulaschma]

Gibt es eine Übersicht welche deutschen Websites betroffen sind/waren?
Also z.B. Online-Shops, Provider wie Vodafone usw.

[Lord Wotan]

Und Banken nicht zu vergessen.

[ShinyMcShine]

In der Tat hat man bisher kaum etwas über die Logins von Banken gelesen...

VG
Shiny

[sei laut]

In der Tat hat man bisher kaum etwas über die Logins von Banken gelesen...
Es schürt Panik, die a) eh schon größer ist als sie sein sollte und b) hast du dadurch nichts gewonnen.
Wie ich schon schrieb, das ist nur eine Lücke von vielen. Außerdem gibt es zielführerende Methoden des Datenklaus.
Mich hat schon immer verwundert, wie man OpenSSL sicher hält, eine Software, auf die sich so viele verlassen. Nun ist die Antwort halt offiziell: Gar nicht.

[mekakic]

Das ist kein normales malloc, was da passiert. Der Speicher hinter den Array-Grenzen ist komplett valide. OpenSSL holt sich halt den Speicher vom OS in größeren Blöcken und arbeitet darauf selbstständig (ähnlich wie Java oder Ruby). Hat halt nur keinen eigenen Bound-Check. Der Grund ist eine reine Performance-Entscheidung. Damit hebelt man natürlich einige andere Sicherheitsfeatures schon direkt da aus,
Ach krass. Deswegen kann ich auch den Reviewer verstehen... haben das OPENSSL_malloc gleich mal überlesen.

Welche Sinn soll das haben? Bitte nicht Geschwindigkeit! :) Dinge wie Heap Fragmentierung o.ä. sollten für OpenSSL ja auch recht egal sein.

[Ganon]

Welche Sinn soll das haben? Bitte nicht Geschwindigkeit! :)

Doch, das steht sogar genau so im Quelltext als Kommentar darüber.

[mekakic]

Das steht doch nur was zum padding? Oder meinst Du eine andere Stelle?
http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=ssl/t1_lib.c;h=a2e2475d136f33fa26958fd192b8ace158c4899d#l3987

Hab gerade in dem Zusammenhang auch noch diesen Beitrag gefunden
http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

[Ganon]

Das hier, wo OPENSSL_malloc definiert wird:

http://git.openssl.org/gitweb/?p=openssl.git;a=blob_plain;f=ssl/s3_both.c;hb=HEAD


#ifndef OPENSSL_NO_BUF_FREELISTS
/* On some platforms, malloc() performance is bad enough that you can't just
* free() and malloc() buffers all the time, so we need to use freelists from
* unused buffers.
[...]
static void *
freelist_extract(SSL_CTX *ctx, int for_read, int sz)
[...]
#define freelist_extract(c,fr,sz) OPENSSL_malloc(sz)


Und genau das hat dazu geführt, das auch das sonst hochsichere OpenBSD betroffen war. Deren malloc ist lahm, ja. Aber dafür prüft das auch jegliche Bereichsüberschreitung.

edit:
Und achja, obwohl da ein ifndef steht... wenn man das abschaltet kompiliert wohl OpenSSL nicht mehr durch bzw. funktioniert nicht mehr, da es seit Jahren der Default ist.

[Gulaschma]

In der Tat hat man bisher kaum etwas über die Logins von Banken gelesen...

VG
Shiny

Also bei der Deutschen Bank steht folgendes:
In den Medien wird zur Zeit über eine Sicherheitslücke in der Verschlüsselungs-Software ‚OpenSSL‘ berichtet.
Das Online-Banking der Deutschen Bank war zu keinem Zeitpunkt davon betroffen

[Eidolon]

Bei der Online-Banking-Lösung der Haspa kommt das besagte OpenSSL-Produkt nicht zum Einsatz. Insofern besteht hier auch keine Gefahr für Online-Banking-Kunden der Hamburger Sparkasse.

[ENKORE]

Sparkassen, die osplus oder wie das hieß einsetzen, sind afaik allesamt nicht betroffen.

[Gulaschma]

Hier noch eine kleine Übersicht:
http://www.faz.net/aktuell/wirtschaft/netzwirtschaft/sicherheitsluecke-heartbleed-war-ihre-lieblingsseite-auch-betroffen-12891505.html

http://weblauscher.com/heartbleed-diese-deutschen-internetseiten-sind-betroffen

Die Hypovereinsbank ist wohl betroffen. DKB angeblich nicht, obwohl ich woanders (Quelle habe ich vergessen) gelesen habe, dass die betroffen waren, es aber schnell gefixt haben.

[=Floi=]

es war auch nicht openssl unsicher, sondern der speichermanager über die hartbeatfunktion. Das ist ein himmelweiter unterschied.

[ENKORE]

es war auch nicht openssl unsicher, sondern der speichermanager über die hartbeatfunktion. Das ist ein himmelweiter unterschied.

:|

...

:facepalm:

[Exxtreme]

http://www.heise.de/security/news/foren/S-In-openssl-ist-eine-Funktion-womit-man-zu-jeder-Adresse-springen-kann-ROP-hack/forum-280853/msg-25327802/read/


Wenn das stimmt ... dann ist Openssl so derbe am A....

[Ganon]

Ja mal schauen was die LibreSSL-Leute noch so alles finden.

[sei laut]

Wenn das stimmt ... dann ist Openssl so derbe am A....
Da fehlen viel zu viele Details und der Typ, der das gepostet hat, verlinkt wild kreuz und quer Zeug, was so nicht zusammengehört.
Verschwörungstheorie incoming in 3..2..1 - sonst fährst du doch auch nicht auf sowas ab.

[Demirug]

Selbst wenn das keine mit Absicht eingebaute Hintertür ist gibt es eigentlich keine Rechtfertigung so etwas in Sicherheitskritischen Code einzufügen. Selbst wenn man es nicht missbräuchlich nutzt spart man sich mit diesem Stück Code nur das nachschauen welche calling rules eine Funktion eigentlich hat. Wenn man nicht mal die Zeit dafür hat will ich nicht wissen was man sonst noch so alles macht ohne genau darüber nachzudenken.

[Exxtreme]

Da fehlen viel zu viele Details und der Typ, der das gepostet hat, verlinkt wild kreuz und quer Zeug, was so nicht zusammengehört.
Verschwörungstheorie incoming in 3..2..1 - sonst fährst du doch auch nicht auf sowas ab.
Mir ging es weniger um die Links sondern um OPENSSL_indirect_call(...).