Herzblut

[Merthos]

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

Na ja, die wechseln regelmäßig und man müsste jeden von Session Keys erwischen...

 

[jahlives]

Na ja, die wechseln regelmäßig und man müsste jeden von Session Keys erwischen...

klar wechseln die regelmässig, sonst wäre es wohl zu einfach
Wenn man aber ein TLS Ticket bekommen könnte, was gemäss Ivan Ristic möglich wäre, dann wären alle damit verschlüsselten PFS Verbindungen im Nachhinein doch entschlüsselbar. Klar bräuchte man auch noch den private Key des Servers.
Das grosse Risiko dieser Lücke ist auch nicht dass man SSL rückgängig machen könnte, sondern mehr dass man an sehr sehr viele Logindaten kommen kann

 

[jahlives]

Gerade zwei interessante Berichte gefunden (leider nur englisch). Gemäss EFF gibt es Hinweise, dass diese Lücke schon deutlich vor der Veröffentlichung am Montag missbraucht wurde. Und zwar mindestens seit November 2013 https://www.eff.org/deeplinks/2014/...gence-agencies-using-heartbleed-november-2013
Die andere Seite befasst sich mit dem "Erfinder" dieser Lücke. Er sagt natürlich war keine Absicht, wollte ich nicht und ist mir durch die Lappen gegangen. Wobei das wohl auch jeder Angeklagte vor Gericht behaupten würde http://www.smh.com.au/it-pro/securi...-inserted-it-deliberately-20140410-zqta1.html

 

[Frogman]

...Die andere Seite befasst sich mit dem "Erfinder" dieser Lücke. Er sagt natürlich war keine Absicht, wollte ich nicht und ist mir durch die Lappen gegangen. Wobei das wohl auch jeder Angeklagte vor Gericht behaupten würde [/url]

Er hat sich wohl auch gegenüber dem Spiegel geäußert, gestern gab's dazu einen Artikel: http://www.spiegel.de/netzwelt/web/...r-schrieb-den-fehlerhaften-code-a-963774.html Den Verdacht, es sei doch wohl eher kein Zufall gewesen (offen geäußert auch durch v. Leitner), wird er wohl kaum komplett ausräumen können.

 

[jahlives]

@Frogman
es ist ja nicht nur die Implementation die äusserst schlampig erfolgte. Auch das Konzept des Heartbeats ist alles andere als über alle Zweifel erhaben: wieso braucht ein Heartbeat einen Payload? Warum kann dieser Payload vom Client beeinflusst werden? Und wieso ist die Länge des Payloads nicht fix, sondern kann vom Client festgelegt werden? Dann noch die Frage wieso 2x ein Length Parameter spezifiziert wird. Einer würde reichen
Und als letztes wieso kann ein Heartbeat bis zu 64K RAM auf der Gegenseite reservieren? Ein Byte würde vollends reichen, wenn man denn unbedingt eine Payload braucht

 

[Mike0185]

Angeblich tauscht auch StartCOM nun kostenlos die Zertifikate aus. Ich probiere es gerade über einen "Revocation Request" mit dem Grund "OpenSSL Bug". Laut einem Forumbeitrag bei Heise ist der Rückruf, entgegen der Angaben von StartCOM, nun doch kostenlos... ich bin gespannt

 

[Frogman]

Auch das Konzept des Heartbeats ist alles andere als über alle Zweifel erhaben: wieso braucht ein Heartbeat einen Payload? Warum kann dieser Payload vom Client beeinflusst werden? Und wieso ist die Länge des Payloads nicht fix, sondern kann vom Client festgelegt werden? Dann noch die Frage wieso 2x ein Length Parameter spezifiziert wird. Einer würde reichen Und als letztes wieso kann ein Heartbeat bis zu 64K RAM auf der Gegenseite reservieren? Ein Byte würde vollends reichen, wenn man denn unbedingt eine Payload braucht

Da stimme ich Dir vollständig zu - und wenn der gute Mann hier so "geschludert" hat (oder eben doch nicht), spätestens beim Code-Review hätte hier korrigiert werden müssen. Mir scheint es nach all den inzwischen bekannten Schlapphut-Initiativen auch durchaus nicht ganz unwahrscheinlich, dass hier im OpenSSL-Projekt mitgemischt wurde - bei dem Verbreitungsgrad wäre es töricht gewesen, diesen Hebel nicht anzusetzen.

Edit:
Ich habe mir gestern mal seine Diss angeschaut - die Abschnitte über Sicherheitsbetrachtungen sind wirklich abenteuerlich knapp - der Prof hat da wohl auch nicht wirklich viel reingeschaut...

 

[Frogman]

Gerade zwei interessante Berichte gefunden (leider nur englisch). Gemäss EFF gibt es Hinweise, dass diese Lücke schon deutlich vor der Veröffentlichung am Montag missbraucht wurde. Und zwar mindestens seit November 2013 https://www.eff.org/deeplinks/2014/...gence-agencies-using-heartbleed-november-2013[/url]

Heise hat's mal auf deutsch formuliert: http://heise.de/-2167934

 

[tops4u]

Ich bin immer noch entgeistert von der *NICHT* Information. myds.synology.com nicht ein Wort... Man wird nun im Nachhinein auch gar nicht mehr rausfinden können wer denn nun alles betroffen war.

 

[wired2051]

Ich gebe zu, ich habe nicht alle Posts hier gelesen. Kann bitte jemand den aktuellen Stand wiedergeben?

Ich habe meine https://USER.dyndns.org:PORT/photo mit http://filippo.io/Heartbleed/ getestet und sie ist VULNERABLE. Aktuelle ist auf der DS209 DSM 4.2-3246 installiert.

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.

Das sehe ich grundsätzlich ja auch so, die Frage ist für mich als nicht-Auskenner: kommt was von Synology und werde ich von der Paketverwaltung informiert werden?

 

[gizmo21]

aktuelles Problem mit Update 2

Heartbleed-Bugfix legt einige NAS-Systeme lahm:
http://www.golem.de/news/synology-d...legt-einige-nas-systeme-lahm-1404-105796.html

Ein Blick in die Synology-Foren zeigt, dass wir nicht allein sind. Es betrifft anscheinend nur wenige Geräte. In einem Thread http://forum.synology.com/enu/viewtopic.php?f=7&t=84286 meldet sich ein Besitzer einer DS112j und vermeldet ein ausgefallenes System. Rückmeldungen gibt es zudem von Nutzern mit den Modellen DS211j, RS214 und weiteren DS112j. Betroffen sind derzeit anscheinend insbesondere Besitzer der Modelle DS112j und RS214. Ein Nutzer berichtet zudem, dass eine Diskstation DS112j zwar vom Synology Assistant noch entdeckt werde, aber der Modelleintrag sei verschwunden, so dass der Assistent nicht wisse, welche DSM-Version installiert werden kann. Ein weiterer Nutzer hat eine Antwort vom Synology-Support erhalten. Der zitierten E-Mail zufolge weiß Synology von dem Problem, geht derzeit aber davon aus, dass nur das Modell DS112j betroffen ist.

Also wenn der Patch jetzt doch noch länger auf sich warten lässt, dann ist es noch wichtiger JETZT die Ports bei von aussen dicht zu machen.

 

[Puppetmaster]

Mir scheint es nach all den inzwischen bekannten Schlapphut-Initiativen auch durchaus nicht ganz unwahrscheinlich, dass hier im OpenSSL-Projekt mitgemischt wurde - bei dem Verbreitungsgrad wäre es töricht gewesen, diesen Hebel nicht anzusetzen.

Auf der anderen Seite ist es töricht zu glauben, dass man damit auf längere Sicht Erfolg haben wird. Der Code ist doch wohl offen und früher oder später wird es entdeckt werden. Die Wellen, die dann geschlagen werden sind hoch, gerade immer unter dem Aspekt der Enthüllungen der jüngeren Vergangenheit.

 

[hopeless]

Angeblich tauscht auch StartCOM nun kostenlos die Zertifikate aus. Ich probiere es gerade über einen "Revocation Request" mit dem Grund "OpenSSL Bug". Laut einem Forumbeitrag bei Heise ist der Rückruf, entgegen der Angaben von StartCOM, nun doch kostenlos... ich bin gespannt

Ich wäre dir sehr dankbar, (solltest du Erfolg haben) wenn du die nötigen Schritte hier dann posten könntest

 

[Frogman]

Auf der anderen Seite ist es töricht zu glauben, dass man damit auf längere Sicht Erfolg haben wird. Der Code ist doch wohl offen und früher oder später wird es entdeckt werden. Die Wellen, die dann geschlagen werden sind hoch, gerade immer unter dem Aspekt der Enthüllungen der jüngeren Vergangenheit.

Da hast Du sicherlich recht - wobei ich fest annehme, dass eben deshalb viele Maßnahmen redundant/diversitär angelegt werden nach dem Motto 'wenn ihr eines entdeckt, haben wir immer noch etwas anderes...'. Und die Spuren sind ja hinreichend gut verwischt, selbst bei den Aktivitäten am NIST, die ja auch nur offenkundig geworden sind, weil Snowden die Unterlagen veröffentlicht hat. Aber wie ja schon anklang, selbst bei öffentlichem Code ist angesichts der Komplexität und Masse nicht immer gewährleistet, dass ein inhaltlich sauberer Review stattfindet.

 

[ottosykora]

Habe da gleich noch Frage zu den Schlüsseln.

Habe also Update gemacht auf die letzte Version von Synology.
Die filipo Site sagt es ist nun alles OK.

Wie geht man jetzt korrekterweise mit den Schlüsseln um?
Hat der Update von Syno auch etwas an den Schlüsseln ersetzt?
Wenn ich den originalen Public Key von der Synology verwende, wurde es nun zusammen mit dem Private Key ersetzt bei dem Update?

Wenn ich einen Selfsigned habe, muss ich den neu erstellen?

 

[Frogman]

Nein, Schlüssel musst Du selbst ersetzen - lies einfach mal weiter oben in diesem Thread, da wurde schon viel dazu geschrieben.

 

[ottosykora]

Nein, Schlüssel musst Du selbst ersetzen - lies einfach mal weiter oben in diesem Thread, da wurde schon viel dazu geschrieben.

ja nur kann ich nicht finden was und wie genau vorgesehen ist.

Kann ich also einen neuen mit der GUI der DS erstellen?
Oder muss ich den extern erstellen und dann importieren?

Wir haben bis jetzt bei den DS die sich im Feldeinsatz befinden die Schlüssel nie geändert, sonder diejenigen verwendet welche drin waren ab Fabrik. Darum dachte ich vielleicht hat Syno das bei dem Update auch gleich erstellen lassen.

 

[Frogman]

Wir haben bis jetzt bei den DS die sich im Feldeinsatz befinden die Schlüssel nie geändert, sonder diejenigen verwendet welche drin waren ab Fabrik. .

Dann einfach über die GUI neu erstellen lassen.

 

[tops4u]

Ich habe einen Schlüssel von RapidSSL (via psw.net) und der wurde mir innert 5 Min ersetzt (kostenlos).

 

[akon1317]

Hallo alle zusammen,

verfolge die Diskussion nun schon länger. Ich setze noch DSM 4.3 ein. Ich glaube seit heute Nachmittag hat Synology gepacht! Habe nun 4.3-3827 Update 1 via Update-Oberfläche installiert. Heartbleed scheint nun in 4.3 gefixt!