Herzblut

[dil88]

Vorsicht, 4.3-3827 Update 1 gibts schon seit ein paar Wochen, da sollte sich in Sachen OpenSSL noch nichts getan haben.

 

[akon1317]

jetzt dachte ich, ich war mal schnell ... Kommando zurück ... also noch kein Heartbleed-Fix für DSM 4.3

 

[jahlives]

bin da gestern auch reingefallen. Es gab zwei Fixes für openssl Probleme. Dieses Update 1 dürfte der Fix für das alte Problem sein. Das neue wird da kaum gefixt sein

 

[Frogman]

Hab's in Post #153 kurz erwähnt (http://www.synology-forum.de/showthread.html?52795-Herzblut&p=420610&viewfull=1#post420610 ) - dabei ist es dann ja fast schon tragisch, dass gerade mit dem Update 1 (mit OpenSSL 1.0.1f) das Problem ins Haus geholt wurde.

 

[bfpears]

"Bislang gibt es von Cisco nur Workarounds, aber noch kaum offizielle Patches."
Quelle: http://www.golem.de/news/heartbleed...d-juniper-produkte-betroffen-1404-105811.html

Da sind wir ja gar nicht so schlimm dran. Obwohl die Kommunikation bei Sicherheitslücken noch viel Spiel nach oben hat.

 

[akon1317]

was mich noch interessieren würde: ich meine mal gelesen zu haben, dass der Zugriff via SSH nicht vom Heartbleed-Bug betroffen ist. Schließt dass auch den Zugriff via SFTP ein? Eine Unsicherheit bleibt für mich aber dennoch: ich nutze den Mailserver der Synology von außen, somit könnte hier also der geheime Schlüssel des SSL-Zertifikats ausgespäht werden und dann zur Entschlüsselung von SFTP-Traffic genutzt werden - sehe ich das richtig?

 

[Frogman]

... Schließt dass auch den Zugriff via SFTP ein?

Nein, SFTP ist nicht betroffen - FTPS dagegen aber schon. Der Traffic bei SFTP wird aber auch nicht über das SSL-Zertifikat abgesichert, sondern über eine kryptografisch starke Verschlüsselung und Eingabe eines Passworts, ist also nicht gefährdet. Bei FTPS (also FTP über TLS) wird das SSL-Zertifikat verwendet, daher ist der Traffic gefährdet.

 

[Butsu]

Verständnisfrage: Wenn ich mit dem Server nicht mit HTTPS: kommuniziere, also nur HTTP:, ist das Ganze dann egal? Oder ist generell entscheidend ob der Server die fragliche Version hatte?
(Ich weiss dass man nach draussen HTTP: nicht nehmen sollte...)

 

[Gnallur]

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

Hallo,
ich hätte da mal noch eine Nachfrage. Mit dem Update 2 wurde ja das Zertifikat der Synology nicht neu erstellt. Das selbst unterzeichnete Zertifikat liegt in unveränderter Form (wie vor dem Update) vor. Verstehe ich jetzt den Beitrag von jahlives richtig, dass es nicht notwendig ist, ein neues, selbst unterzeichnetes Zertifikat, nach Installation des Update 2 zu erstellen. Wenn aber jetzt durch den Heartbleed-Bug meine Login-Daten der DS212+ ausgelesen worden wären, dann wäre es doch möglich, dass sich auch jemand meine SSL-Keys besorgt hat??

Wäre es nicht zwingend erforderlich, dass nach dem Update 2 in jedem Fall ein neues, selbst unterzeichnetes Zertifikat zu erstellen ist!!!???

Ich habe mir mal die im DSM die Seite zur Zertifikatserstellung angesehen und habe keine Ahnung, was ich in die entsprechenden Felder eintragen muss. Könnte mir da mal jemdand Hilfestellung gebe? Die Anleitung aus dem Wiki bekomme ich nicht geregelt, weil ich mich mit Putty und Co nicht auskenne. Ich habe Webmin als Paket installiert und könnte über Webmin auf die Syno gehen.

Gruß aus dem Saarland

Stephan

 

[Frogman]

Verständnisfrage: Wenn ich mit dem Server nicht mit HTTPS: kommuniziere, also nur HTTP:, ist das Ganze dann egal? Oder ist generell entscheidend ob der Server die fragliche Version hatte?
(Ich weiss dass man nach draussen HTTP: nicht nehmen sollte...)

Solange Du nur unverschlüsselte Protokolle wie hier http nutzt (d.h. auch kein Port am Router auf einen SSL-verschlüsselten Dienst weitergeleitet ist), passiert nichts.

 

[Butsu]

Aber: Wenn der Server anderweitig HTTPS: verwendet hat und die betroffene Version drin war kann doch trotzdem Datendiebstahl erfolgt sein, z.B. die Login-Daten?
Wenn ich HTTP: nutze ist zwar meine Verbindung nicht betroffen, aber durch andere Verbindungen zum gleichen Server kann das Problem bestanden haben.

 

[Frogman]

Aber: Wenn der Server anderweitig HTTPS: verwendet hat und die betroffene Version drin war kann doch trotzdem Datendiebstahl erfolgt sein, z.B. die Login-Daten?

Du hast meinen Post aber schon gelesen, oder? Deswegen schrieb ich ja "d.h. auch kein Port am Router auf einen SSL-verschlüsselten Dienst weitergeleitet ist" - wenn also von außen kein verschlüsselter Dienst erreichbar war, dann kann man über diesen Bug auch keine Schlüssel oder Passwörter auslesen.

 

[jahlives]

was man nicht vergessen sollte: es braucht nicht unbedingt offene Ports ;-) Ein einfaches wget https:// nach aussen würde reichen wenn der Server auf der Gegenseite ein Heartbeat durchschickt

 

[Frogman]

Ok, hast recht, prinzipiell auch dann - aber so müßte ja der betreffende Server auf der Gegenseite den Mißbrauch provozieren (also payload mit manipulierter length) und es müßte explizit das wget über SSL dorthin angestoßen werden.

 

[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

Leider nicht bei den Class 1-Kunden. Habe es ja (wie oben im Zitat geschrieben) probiert, bekam nur eine Email, dass ich keine Zahlungsmodalitäten angegeben habe und der Vorgang $ 25 kostet. Daher wurde der Auftrag dann gleich storniert. Ich werde wahrscheinlich nun eines kaufen. Habe bei PSW-Group derzeit ein kostenloses 30-Tage-Zertifikat. Hat super geklappt. Die tauschen auch derzeit für alle Kunden kostenlos aus. Das vollwertige kostet 15 im Jahr. Oder kennt noch jemand andere, günstigere Alternativen?

 

[fbl1]

Kann PSW nur empfehlen. Hab mir gestern eins geholt. Ging ruck zuck und man hat nicht das Theater bei einem tausch.
Also günstiger hab ich nichts gefunden. Ist jetzt aber auch nicht die Welt.

 

[Frogman]

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 ;-)
...

Um das von jahlives Gesagte noch einmal aufzunehmen, hier mal ein Link auf einen aktuellen Heise-Artikel. Da geht es um die Abschätzung der Gefahr, dass tatsächlich ein Key gezielt ausgelesen wird. Man stellt in dem Test des Anbieters CloudFlare fest, dass dafür zwar unter Umständen eine Menge Serveranfragen gestellt werden müssen, um einen Treffer zu landen - so eben gemacht ist das also nicht unbedingt. Aber offenbar gelingt das auch nach längerer Laufzeit durchaus noch.

 

[jahlives]

@Frogman
sehr interessanter Bericht
Habe es bei mir selber auf einigen Servern getestet und konnte nur nach Boot resp Restart des Webservers an die Keys ran. Hoffe Cloudflare resp die erfolgreichen Tester geben noch mehr Infos raus was genau sie gemacht haben. Nicht dass die Tester einen Weg gefunden haben den nginx zu restarten und damit die Schlüssel neu einzulesen ;-)

 

[Frogman]

Nicht dass die Tester einen Weg gefunden haben den nginx zu restarten und damit die Schlüssel neu einzulesen ;-)

Zumindest schreibt CloudFlare "We confirmed that all individuals used only the Heartbleed exploit to obtain the private key."
In 'ner Woche oder so will Fedor seinen Angriff veröffentlichen, schreibt er im Blog.

 

[gizmo21]

Neuigkeiten zum 4.3 Update:

http://forum.synology.com/enu/viewtopic.php?f=229&t=84291#p317422

"We are working on update for DSM 4.2 & DSM 4.3. DSM 4.2 update will be available in one week. For users who prefer using DSM 4.3, the update will be ready before the end of April."

Just received this in an email from Synology.

Reichlich spät würde ich sagen, d.h. also meine Syno wird 2 Wochen lang nicht von aussen erreichbar sein - grrrr


---
btw. hier gibt' s noch ne Anleitung die angeblich die bricked ds112j von fehlgeschlagenem 5.0 Update2 wieder fit macht: https://www.facebook.com/synology/p...omment_id=31356565&offset=0&total_comments=56