Herzblut

[jahlives]

@hopeless
aktuell ist mail.selfhost.de gepatcht. Ob's vorher auch schon so war ist schwierig zu sagen. Das kann nur selfhost selber beantworten. Je nach Centos Version ist es gut möglich dass eine 1.0.0 oder sogar noch eine 0.9.8 läuft. Ohne die Centos Version zu kennen kann man nichts genaueres sagen.

Zudem möchte ich noch folgendes klarstellen: das leaken von private Key Material ist nur unter sehr engen Bedingungen möglich. Nämlich kurz nach dem Boot resp kurz nach dem Start der Anwendung welche libssl verwendet. Gar nichts resp nur Datenmüll bekommt man von Systemen, die zwar anfällig auf Heartbeat sind, aber ihren freien Speicher regelmässig überschreiben.

Das Prinzip ist erschreckend einfach: das Heartbeat Paket kennt zwei Length Parameter. Nach dem ersten Parameter reserviert der Server einen Buffer im Speicher und nach dem zweiten füllt er diesen Buffer mit der dem Inhalt des Pakets. Das Problem ist, dass die Werte dieser beiden Parameter in keinster Weise geprüft werden. Wenn jetzt ein Client im ersten Wert sagt 64K dann im zweiten aber ne fette 0 schickt passiert folgendes: der Server reserviert 64K Buffer. Dann schreibt er 0 mal den Inhalt des Pakets in der Speicher. Ergo wird kein einizges Bit verändert. Dann wird der Buffer zurück an den Client geschickt. Was in dem Block steht gehört eigentlich zu anderen Anwendungen welche diesen Speicher zuvor freigegeben haben müssen. Je nachdem welcher Anwendung der Block vorher gehörte bekommt man dann sehr unterschiedlichen Inhalt. Sehr oft bekommt man Request Header bei Webservern.

Auch nicht vergessen: sehr viele Geräte brauchen auch openssl z.B. Router
Bei meinem aktuellen pfsense ist es z.B. so dass man kurz nach dem Login via Webinterface, das verwendete Passwort bekommt
Man bekommt also nur recht aktuelle Sachen. Drum ist es auch so unwahrscheinlich dass man Key Material bekommen kann, wenn der Server/Dienst mal eine bestimmte Laufzeit hat. Zudem sind Systeme mit knapp bemessenen RAM weniger anfällig auf Key leaking. Denn mit weniger RAM wird ein bestimmter freier Block schneller wiederverwendet und damit unerreichbar für den Bug. Also lohnt es sich wohl am meisten für die User der j-Modelle und die User mit den + Modellen erhöhen die Chancen auf geleakte private Keys
Unangreifbar dürfte ein System sein, welches ständig vollen RAM hat und swappen muss ;-)

 

[Pulpi]

Die Seiten zeigen mir an das es nun gefixt wurde, allerdings hat sich an meiner OpenSSL Version nichts geändert, ist das bei euch auch so?

 

[jahlives]

0.9.8 ist NICHT betroffen. Aber wenn ich genau hingucke, dann hast du ipkg openssl und damit bringt ein Patch von Syno rein gar nichts

 

[DarkSoul]

Du kannst mit Sicherheit nicht mein "Wissen zum Thema Test und Multiprojektmanagement" beurteilen. Abgesehen davon ist das Thema seit Montag bekannt, heute ist Donnerstag - von einem Unternehmen, das seine Produkte massiv mit einer externen Nutzung bewirbt, erwarte ich mehr Aktivität. Auch andere Firmen sind betroffen mit mindestens ebensolch komplexen Produkten, und die haben ihre Updates oftmals bereits am Dienstag im Feld gehabt.

Augenscheinlich ja doch, zum einen weil mit Update 2 der Bug beseitigt worden ist und, für den Fall dass du das nicht mitbekommen hast, das Update 2 schon viel früher auf dem Server gesichtet aber nicht ausgerollt worden ist, Synology wohl allem Anschein nach noch mit Hochdruck daran gearbeitet den Bugfix mit reinzunehmen. Zumal auch Synology sicher nur begrenzte Kapatitäten hat, so groß wie die Testmannschaften der Firma für die ich schufften darf sicher nicht und das ist ebenfalls kein reines Softwareunternehmen. Montag bekannt, Donnerstag gefixt, für mich eine sehr gute Leistung, vor allem weil neben Test und Entwicklung auch der formale Kram gehört. Aber wenn du meinst du kennst dich so gut aus, dann glaub das ruhig weiter. Trotzdem ein schönes Wochenende!

Edit: Wie man sieht scheint deren Testabteilung mit der Hardwarevielfalt nach wie vor überfordert zu sein, oder mit den gesteckten Zeitvorgaben, wahrscheinlich sogar beides: http://www.synology-forum.de/showthread.html?52879-Nach-Update-5.0-4458-Update-2-kein-DSM-mehr!! Wenn ich nicht beruflich schon so viel mit dem Thema zu tun hätte, würde ich ja liebend gerne bei Beta-Tests mitmachen, doch leider kann ich es nicht brauchen ein instabiles System daheim stehen zu haben und zahlreiche Threads scheinen auch den Verdacht zu bestätigen, dass nicht nur deren Testabteilung überfordert ist... schade, leider ist das mittlerweile bei vielen Herstellern so (z. B. auch bei Garmin, Samsung, HTC, etc.).

 

[fbl1]

Und andere grössere Firmen haben es auch nicht auf die Reihe gebracht. Also bitte. Schön spielen. Soll ja nicht ausarten.

 

[ottosykora]

0.9.8 ist NICHT betroffen. Aber wenn ich genau hingucke, dann hast du ipkg openssl und damit bringt ein Patch von Syno rein gar nichts

wenn ich 4.3 habe und ssl mit ipkg installiere, bringt es etwas? Ist das Problem dann gelöst? Funktioniert alles andere dann normal weiter?

 

[hopeless]

@hopeless
aktuell ist mail.selfhost.de gepatcht. Ob's vorher auch schon so war ist schwierig zu sagen. Das kann nur selfhost selber beantworten. Je nach Centos Version ist es gut möglich dass eine 1.0.0 oder sogar noch eine 0.9.8 läuft. Ohne die Centos Version zu kennen kann man nichts genaueres sagen.

Ja, aber das Patchen der OpenSSL Version allein bringt ja nichts, denn wenn ich Heise richtig verstehe müssen zwingen auch die Zertifikate getauscht werden.

<Zitat (*)>
Da die Lücke relativ einfach zu finden und auszunutzen ist, besteht eine realistische Gefahr, dass andere sie bereits früher entdeckt und systematisch Server-Schlüssel eingesammelt haben, ohne dabei Spuren zu hinterlassen. Selbst Systeme, die sehr schnell nach Bekanntwerden des Bugs aktualisiert wurden, müssen deshalb als kompromittiert gelten. Dass die geheimen Server-Zertifikate bereits kopiert wurden, ist so wahrscheinlich, dass deren Austausch notwendig ist.
</Zitat (*)>

Ob die Systeme von Selfhost betroffen sind oder nicht, können wir beide wohl nicht beurteilen, daher ist eine Information an die User der Dienste für mich in diesem Fall zwingend, nichts zu tun ist ganz schlecht. Und darauf sollte ein Dienstleister der auch Mailhosting betreibt, IMHO von alleine drauf kommen .


(*) http://www.heise.de/newsticker/meldung/Heartbleed-SSL-GAU-Neue-Zertifikate-braucht-das-Land-2166639.html

 

[Frogman]

Augenscheinlich ja doch, zum einen weil mit Update 2 der Bug beseitigt worden ist und, für den Fall dass du das nicht mitbekommen hast, das Update 2 schon viel früher auf dem Server gesichtet aber nicht ausgerollt worden ist, Synology wohl allem Anschein nach noch mit Hochdruck daran gearbeitet den Bugfix mit reinzunehmen. Zumal auch Synology sicher nur begrenzte Kapatitäten hat, so groß wie die Testmannschaften der Firma für die ich schufften darf sicher nicht und das ist ebenfalls kein reines Softwareunternehmen. Montag bekannt, Donnerstag gefixt, für mich eine sehr gute Leistung, vor allem weil neben Test und Entwicklung auch der formale Kram gehört. ...
Edit: Wie man sieht scheint deren Testabteilung mit der Hardwarevielfalt nach wie vor überfordert zu sein, oder mit den gesteckten Zeitvorgaben, wahrscheinlich sogar beides: http://www.synology-forum.de/showthread.html?52879-Nach-Update-5.0-4458-Update-2-kein-DSM-mehr!! ...

Na, was denn nun? Gute Leistung oder nach wie vor überfordert?
Augenscheinlich scheinst Du Dich doch weit aus dem Fenster zu lehnen. Der OpenSSL-Bug wurde von den Entdeckern am 7.4. veröffentlicht - die erste Version vom Update 2 lag aber bereits am 3.4. auf dem Synology-Server... Aber glaub' mal weiterhin, dass hier Planung dahintersteckt. Schönes Wochenende!

 

[tops4u]

Es geht ja vor allem auch darum wie Firmen damit umgehen. Bei Synology war ja nicht nur die Firmware betroffen sondern auch der DynDNS Dienst und da hapert es ja scheinbar mit der Information.

Leider ist das auch bei anderen Betroffenen Firmen so, z.B. bei meinem Kreditkarten Herausgeber welcher Betroffen war, es jedoch nicht nötig findet die eigenen Nutzer darüber zu informieren ausser mit einer lapidaren kurzen Notiz welche auf der Webseite vorbeihuscht man sei auch betroffen gewesen nun sei aber alles wieder gut. Kein Mail. Keine Aufforderung zum Passwortwechsel... Dabei hätte man da Zugriff auf sensitive Daten. Login Daten konnte man problemlos abgreifen.

Das es auch anders geht hat z.B. heute wunderlist.de bewiesen indem Sie allen Usern ein Mail mit Erklärungen geschickt haben, alle User ausgeloggt und gebeten haben ein neues Passwort zu vergeben. Vorbildlich!

 

[Frogman]

Ja, aber das Patchen der OpenSSL Version allein bringt ja nichts, denn wenn ich Heise richtig verstehe müssen zwingen auch die Zertifikate getauscht werden. ..

Na ja, zwingend... Ein Angreifer könnte grundsätzlich ohne Schlüsseltausch mit den zuvor gehorteten Schlüsseln weiterhin Datenverkehr entschlüsseln. Werden die Zertifikate aber getauscht, könnte er nur noch die unter Umständen in der Zeit zuvor bis zum Schlüsseltausch aufgezeichneten Daten entschlüsseln - alles danach wäre dann sicher.

 

[tops4u]

Na ja, zwingend... Ein Angreifer könnte grundsätzlich ohne Schlüsseltausch mit den zuvor gehorteten Schlüsseln weiterhin Datenverkehr entschlüsseln. Werden die Zertifikate aber getauscht, könnte er nur noch die unter Umständen in der Zeit zuvor bis zum Schlüsseltausch aufgezeichneten Daten entschlüsseln - alles danach wäre dann sicher.

Hätte man bereits vorher PFS verwendet wäre selbst das nicht möglich.

 

[hopeless]

<zitat>
Selbst Systeme, die sehr schnell nach Bekanntwerden des Bugs aktualisiert wurden, müssen deshalb als kompromittiert gelten.
Dass die geheimen Server-Zertifikate bereits kopiert wurden, ist so wahrscheinlich, dass deren Austausch notwendig ist.
</zitat>

Alles andere ist De-Mail

Gerade den Artikel gelesen:
http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html

Das ist wirklich so schlecht programmiert, da könnte man fast von Absicht ausgehen!

 

[Frogman]

Alles andere ist De-Mail

De-Mail ist im Standard auch nur ein TLS-gesicherter SMTP - mitlesen inklusive.

 

[ramoneastral]

nun blutet mein herz wirklich. hab (gestern / vorgestern) wohl die erste version von 4458 v2 eingespielt und openssl version behauptet nun 1.0.1f (6 jan 2014) . dann war ich wohl zu früh... wie bekomme ich die 4458 update2 vom 10.4 nun rein ? ... das edit der version cnf ( wiki ) hat die gui zwar verändert aber es behauptet immer noch up to date zu sein... und bietet keine erfrischung an

thx

 

[Frogman]

Hier per Hand herunterladen und manuell einspielen.

PS: Deine Signatur ist noch auf dem alten Stand...

 

[ottosykora]

also jetzt verstehe ich nicht ganz:

habe soeben eine 211+ via GUI auf -2 updated.

Da steht Datum 9.4

Habe jetzt den File von dem Link da geladen, habe versucht es updaten, aber es sagt diese Version sei älter als die installierte.

Wird der Update via GUI nicht vollständig gemacht?


filipo test sagt es sei alles nun OK

 

[Pulpi]

Tja, per IPKG kann ich zumindest nicht mein OpenSSL aktualisieren, da heißt es dann nur das 0.9.8 die aktuellste Version ist

 

[Thorndike]

Sei doch froh, 0.9.8 ist noch nicht von dem Bug betroffen.

Das Update für 4.3 ist auch noch nicht in Sicht, jetzt kann sich meine Synology noch nicht einmal mehr mit dem Updateserver verbinden. Glücklicherweise habe ich die PhotoStation als letzte Anwendung auf der Syno jetzt hinter einem SSL Proxy auf einem Debian Server versteckt auf dem auch alles andere läuft für das ich einmal eine Syno benutzt hatte. Wenn ich dann sehe wie das Update 2 für 5.0 eingeschlagen ist können sie sich das 4.3 Update wirklich schenken.

 

[jahlives]

es ist in der Praxis kaum möglich den Schlüssel zu leaken, wenn der Server mal eine bestimmte Uptime hat. Nur in einer kurzen Zeitspanne nach dem Boot resp dem Restart der Anwendung welche libssl verwendet kann man allenfalls Key Material auslesen. Es hat niemand bis jetzt geschafft vorsätzlich Schlüssel auszulesen, das klappt wenn dann nur zufällig und nur kurz nach dem Start ;-)
@topsu
wenn man es für möglich hält dass einem die Schlüssel ausgelesen werden können, dann muss man auch PFS als "geknackt" anschauen. Denn steht ein alter TLS Session Key in dem Block, dann kann man alle damit verschlüsselten PFS Sessions entschlüsseln

 

[Puppetmaster]

es ist in der Praxis kaum möglich den Schlüssel zu leaken, wenn der Server mal eine bestimmte Uptime hat. Nur in einer kurzen Zeitspanne nach dem Boot resp dem Restart der Anwendung welche libssl verwendet kann man allenfalls Key Material auslesen. Es hat niemand bis jetzt geschafft vorsätzlich Schlüssel auszulesen, das klappt wenn dann nur zufällig und nur kurz nach dem Start ;-)

Das ist auch einer der Gründe, weswegen ich jetzt nicht in Panik verfalle und auf Teufel komm' raus jeden nur irgendwo auffindbaren Patch von Synology aufspiele.
Ich seh's eher gelassen und warte, bis was brauchbares auf dem "Markt" ist, mit dem ich nicht Gefahr laufe, meine DS in der Art und Weise zu schützen, dass sie durch den Patch gänzlich ausser Gefecht gesetzt wird.

Ich find's einfach nur erschreckend, was ich da so alles lese.