News Schwere Sicherheitslücke im TLS-Protokoll von OpenSSL

Marc_N schrieb:
Ich würd' erstmal schauen, ob dort überhaupt eine der betroffenen Versionen von OpenSSL (1.0.1 -> 1.0.1f) installiert ist.

Yay! Verison 0.9.8j. Jetzt zahlt es sich aus dass man da immer nur absolut notwendige Updates bereitgestellt hat. Steinzeitsoftware FTW :D
Aber 0.9.8 hat bestimmt auch noch irgendwelche Klopfer drin, nehme ich an. Mal zur Sicherheit Googlen.

Daaron schrieb:
Stell dir vor, eine solche Lücke würde in Closed Source auftauchen, und der Support-Zeitraum ist rum oder der Hersteller ist patchfaul.

Ich stell mir lieber vor dass der Fehler jetzt dick und fett im Quellcode drin stand, 2 Jahre lang nicht entdeckt wurde (obwohl ja angeblich immer sooo viele Leute auf den Code schauen) und böse Buben ihn vielleicht schon 1,5 Jahre ausnutzen um Schindluder zu treiben. Weiterhin stelle ich mir vor, dass der Normaluser davon gar nichts mitbekommt und dass noch einige Monate, wenn nicht Jahre, angreifbare Systeme im Netz erreichbar sind. Wer haftet jetzt eigentlich für eventuell entstandene Schäden? Zum Beispiel das Austauschen von Zertifikaten wegen Kompromittierungsverdacht?
 
Zuletzt bearbeitet:
Daaron schrieb:
(...) Ich hab ihn vorhin in Debian 7 und Ubuntu 12.04 eingespielt. Bei CentOS 6 bin ich mir noch nicht ganz sicher, ob er bereits im Repo ist. (...)

Reicht das übliche apt-get update & upgrade aus?
 
zumindest bei Debian 7 ja. (Die richtige Version ist 1.0.1e-2+deb7u5)
Danach noch den Service (oder gleich den ganzen server) durchstarten
 
Die "ganz alten" Android Versionen sind nicht betroffen. "Erst" mit https://android.googlesource.com/platform/external/openssl/+/android-4.1.1_r1/openssl.version (android-4.1.1_r1) gab es "OPENSSL_VERSION=1.0.1c". Außer der Hersteller selbst (HTC, Samsung...) hätte schon früher 1.0.1x eingesetzt, was ich bei diesem "faulen" Pack ;) als eher unwahrscheinlich einstufen würde.

Mac OS X Mavericks ist übrigens auch nicht betroffen da dort eine ältere Version eingesetzt wird.

Google will ja beim Chrome von NSS auf OpenSSL wechseln. Ist man im Zuge dessen beim Sicherheitsteam von Google auf den Bug gestoßen (Code-Review)? Gibt es dazu irgendeine Veröffentlichung, Blog-Eintrag ...
Hat eigentlich google andere (große) Firmen bereits letzte Woche informiert oder war das Codenomicon?
 
DocWindows schrieb:
Ich stell mir lieber vor dass der Fehler jetzt dick und fett im Quellcode drin stand, 2 Jahre lang nicht entdeckt wurde (obwohl ja angeblich immer sooo viele Leute auf den Code schauen) und böse Buben ihn vielleicht schon 1,5 Jahre ausnutzen
Die selbe Situation hast du aber auch bei Closed Source. Wenn eine Lücke entdeckt & gemeldet wird, dann wurde sie vielleicht schon Wochen früher von anderen Leuten entdeckt und nicht gemeldet.
Es ist ziemliches Pech, dass ausgerechnet hier die Code Reviews gescheitert sind. Murphy halt.

ascer schrieb:
Reicht das übliche apt-get update & upgrade aus?
plus "service XYZ restart" halt... Es geht also nicht ohne ein paar Sekunden Downtime.
Wichtig wären hier z.B. die Dienste für HTTP, Mail, SSH und FTP.
 
@Daaron: Nein, die selbe Situation habe ich nicht, da bei Closed Source der Quellcode nicht allgemein zur Verfügung steht. Man müsste da schon das Binary analysieren.

Ich frage mich ob die Entdecker dieser OpenSSL-Lücke auch darauf gestoßen wären wenn sie Binärdaten hätten analysieren müssen.
Ich persönlich glaube nicht dass sie sich ohne Quellcodeeinsicht überhaupt mit der Bibliothek beschäftigt hätten. Sowas tun eigentlich immer nur Leute die a) Geld dafür bekommen oder b) etwas Böses im Schilde führen (und dadurch dann Geld bekommen ;) )

Darüberhinaus würde ich es nicht "Pech" nennen dass die Code Reviews her gescheitert sind.
Gerade weil der Code offen daliegt und es eine so zentrale, sicherheitsrelevante Technologie ist hätte ich erwartet dass es besonders genau beäugt wird.
Möchte nicht wissen was in anderen, nicht so sicherheitsrelevanten Biobliotheken alles für Klopper drin sind.
 
Zuletzt bearbeitet:
Wenn sowohl VPN-Server als auch Client von einem selbst betrieben werden, ist diese Lücke doch eher bedeutungslos oder?
Weil so wie ich das verstanden habe, kann nur ein ins VPN eingewählter Rechner den Angriff durchführen.
Oder habe ich da etwas falsch verstanden?

EDIT: Bitte alles vergessen, was ich geschrieben habe. Ich Idiot hab an OpenVPN gedacht. Sorry.
:hammer_alt::hammer_alt::hammer_alt::hammer_alt::hammer_alt::hammer_alt:
 
Zuletzt bearbeitet:
Sehe ich das richtig, dass auch die Server auf unsere Geräte (PC, Smartphone) zugreifen und den Arbeitsspeicher auslesen können?

Und da anscheinend so ziemlich alle Dienste im Internet betroffen sind, können wir eigentlich ALLE Passwörter ändern.

Das stellt den NSA-Skandal ja mal sowas von in den Schatten...
 
Welche Versionen sind denn bei Ubuntu 12.04 LTS die gepatchten?
Diese hier?

Heisst, wenn mein Server mir folgendes anzeigt bei einem: dpkg -l | grep openssl; dann sollte es doch eigentlich passen oder?

server.JPG


By the way: Wie verhalten sich denn Systeme die hinter einem Reverse-Proxy laufen? Hier wird das SSL doch über den Proxy benutzt und nicht primär auf dem Server oder hab ich nen Denkfehler?
 
Kann ich bei Firefox einstellen, dass er die betroffenen Versionnen blockiert?
 
@iceview
Siehe Changelog der Pakete

openssl (1.0.1-4ubuntu5.12) precise-security; urgency=medium

* SECURITY UPDATE: side-channel attack on Montgomery ladder implementation
- debian/patches/CVE-2014-0076.patch: add and use constant time swap in
crypto/bn/bn.h, crypto/bn/bn_lib.c, crypto/ec/ec2_mult.c,
util/libeay.num.
- CVE-2014-0076
* SECURITY UPDATE: memory disclosure in TLS heartbeat extension
- debian/patches/CVE-2014-0160.patch: use correct lengths in
ssl/d1_both.c, ssl/t1_lib.c.
- CVE-2014-0160

-- Marc Deslauriers <marc.deslauriers@ubuntu.com> Mon, 07 Apr 2014 15:45:14 -0400

Was mich da etwas schockiert ist "urgency=medium". Was ist dringender als ne Memory Disclosure in der Verschlüsselung?
 
Also sowohl mein Arbeits-PC hier als auch unser Ubuntu 12.04 Server hatten den Patch heut vormittag (9-10 rum) in der Liste. Wenns bei dir noch nicht drin ist: verwendest du einen Mirror, z.B. von deinem Hoster? Evtl. ist selbiger noch nicht up to date. Hetzner hats auf jeden Fall schon in den Mirrors.
Ansonsten.. apt-get update
 
Sehe ich das richtig, dass das Problem nur bei Geräten von Bedeutung ist, die als Server Dienste für andere Clients via OpenSSL zur Verfügung stellen? Dann wären ja die ganzen Androiden ab 4.1.1 zwar betroffen, da sie jedoch nur Clients sind wäre das halb so schlimm. Genauso wie NAS-Server, die nur zur Dateifreigabe dienen und KEINEN Webserver aktiviert haben...

Oder sehe ich das falsch?

EDIT:
Aus dem Artikel bei den Kollegen von teltarif.de liest es sich genau so, wie ich es vermute:
"Wer einen Webserver oder einen E-Mail-Server betreibt, sollte zeitnah dieses Update durchführen", sagte Garbsch.
 
Zuletzt bearbeitet:
Gut wäre es aber, den Clienten so einzustellen, dass er die Verbindung ablehnt, falls der Server die unsichere OpenSSL-Version verwenden möchte. Kann ich sowas im Firefox einstellen?
 
Daaron schrieb:
Also sowohl mein Arbeits-PC hier als auch unser Ubuntu 12.04 Server hatten den Patch heut vormittag (9-10 rum) in der Liste.
Debian testing hatte bis vorhin auch noch keinen Patch, afaik war 1.0.1f aktuell. Glaub stable/updates hatte schon ein 1.0.1g drin stehen, da bin ich mir aber grad nicht sicher.
 
Der Artikel liest sich als gäbe es ein Problem mit dem TLS Protokoll, dem ist nicht so. Es gibt ein Problem mit der *Implementation* des TLS Protokoll in OpenSSL.



freacore schrieb:
Gut wäre es aber, den Clienten so einzustellen, dass er die Verbindung ablehnt, falls der Server die unsichere OpenSSL-Version verwenden möchte. Kann ich sowas im Firefox einstellen?

Nein das geht nicht und wäre auch vollkommen sinnlos, den nur weil die Software aktualisiert wurde heißt dass nicht dass der private Key vorher nicht trotzdem kompromittiert wurde. Außerdem gibt es im TLS handshake keinen Austausch irgendwelcher release Informationen.
 
In den Heartbeat-Paketen werden Parameter nicht überprüft, sodass ein für den Datendiebstahl präpariertes Paket relativ leicht einzuschleusen ist.
Kann das mal wer näher erläutern? Ein Heartbeat liest sich für mich wie NOOP bei FTP oder einem simplen Ping. Wie genau kann es sein, dass ein solche Paket so tief ins System kann?
 
Der YouTuber MaxFPS hat ein Video dazu gemacht. Kannst ja mal reinschauen. Hier eine Seite mit der man Seiten auf den Bug testen kann: http://possible.lv/tools/hb/

EDIT:
Mindfactory.de ist sogar jetzt noch betroffen :freak:

MfG

Sennin
 
Zurück
Oben