News Schwere Sicherheitslücke im TLS-Protokoll von OpenSSL

freacore schrieb:
Kann ich bei Firefox einstellen, dass er die betroffenen Versionnen blockiert?

Firefox nutzt kein OpenSSL, sondern NSS. Du kannst also entspannt weiter surfen. ;)

Btw welcher Browser nutzt denn überhaupt OpenSSL? IE und Chrome ja auch nicht, und mir dünkt, dass Apple bei Safari auch eigene Wege geht...
 
Es geht nicht um Clients wie Browser, sondern um TLS geschützte Serverandwendungen wie Webserver oder Mailserver. Auch wenn dein TLS client NaCl von DJB höchstpersönlich nutzt, hilft dir das nichts wenn der private Schlüssel des Servers kompromittiert wurde. Entspanntes weitersurfen ist erstmal nicht drinnen und client-seitig könnt ihr dagegen absolut nichts tun.
 
Jop, so gesehen kann man natürlich nicht viel tun... außer vielleicht, man beschränkt sich auf Server, die PFS anbieten. Dann sollte es ja trotz etwaig bekanntem key nicht möglich sein, die Sitzung zu entschlüsseln... oder hab' ich da was übersehen?
 
Wenn der komplette Traffic von einem Angreifer aufgezeichnet worden ist und er an den Private Key kommt ist PFS auch nicht mehr gegeben. Wenn er natürlich erst mittendrin anfängt mitzuschneiden dann siehts anders aus.
 
Ich wollte meinen kleinen Server dahingehend aktualisieren, aber er findet kein Update dafür. Ich habe centOS 6.5:

# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

ein:
# yum update
Loaded plugins: fastestmirror, priorities, replace
Loading mirror speeds from cached hostfile
* atomic: www7.atomicorp.com
* epel: ftp.uni-koeln.de
386 packages excluded due to repository priority protections
Setting up Update Process
No Packages marked for Update
zeigt bei mir aber keinerlei neue Updates an. Hatte erst vor kurzem eines gemacht. Wie komme ich an das Update ran? Sollte das nicht mit "yum update" automatisch verfügbar sein? ^^°


Wenn ich dies eingebe zeigt er mir eine neue Version an:
# rpm -q --changelog openssl | less
* Mon Apr 07 2014 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-16.7
- fix CVE-2014-0160 - information disclosure in TLS heartbeat extension
 
Falc410 schrieb:
Wenn der komplette Traffic von einem Angreifer aufgezeichnet worden ist und er an den Private Key kommt ist PFS auch nicht mehr gegeben.

Hm? Meinem Verständnis nach soll PFS doch genau das verhindern, da sich die Session-Keys trotz Kenntnis des private keys nicht nachträglich rekonsturieren lassen.

Wenn er natürlich erst mittendrin anfängt mitzuschneiden dann siehts anders aus.

Ich denke, problematisch wirds erst, wenn es gelingt, die Session-Keys zeitgleich aus dem Speicher zu "klauen". Dann müsste man diesen aber qausi ständig überwachen. Aber vielleicht phantasiere ich mir jetzt auch grade was zusammen... ;)
 
Goldilox schrieb:
Jop, so gesehen kann man natürlich nicht viel tun... außer vielleicht, man beschränkt sich auf Server, die PFS anbieten. Dann sollte es ja trotz etwaig bekanntem key nicht möglich sein, die Sitzung zu entschlüsseln... oder hab' ich da was übersehen?

Wenn der private Key kompromittiert ist weißt du aber nicht ob du mit dem wirklichen Server oder mit einem MITM sprichst. PFS schützt dich davor nicht.



Falc410 schrieb:
Wenn der komplette Traffic von einem Angreifer aufgezeichnet worden ist und er an den Private Key kommt ist PFS auch nicht mehr gegeben. Wenn er natürlich erst mittendrin anfängt mitzuschneiden dann siehts anders aus.

PFS schützt den (aufgezeichneten) Verkehr auch wenn der private Key kompromittiert wurde, ansonsten wäre PFS ad absurdum geführt. Wovor PFS nicht schützen kann ist ein MITM Angriff, denn dass hat mit PFS nichts zu tun.
 
Bei PFS muss aber in der ersten Nachricht erst ein Sitzungsschlüssel ausgehandelt werden, und wenn der Angreifer den auch mitbekommen hat dann hast du kein PFS mehr. Deswegen habe ich ja geschrieben, wenn er die erste Nachricht schon mit aufgezeichnet hat, kann er diese nachträglich mit dem Private Key entschlüsseln und so an den Sitzungsschlüssel rankommen.

Beides ist extrem unwahrscheinlich aber möglich.

@Katsumi: Mach das atomic repo aus (/etc/yum.repos.d/atomic.repo auf enabled=0) und probier dann mal die offiziellen repos, da ist es drin.
 
Da hast du etwas falsch verstanden, dem ist nicht so. Ansonsten wäre PFS in 99% der Fälle eh sinnlos. Der Sitzungschlüssel wird ja nicht in Klartext ausgehandelt.
 
luky37 schrieb:
Wenn der private Key kompromittiert ist weißt du aber nicht ob du mit dem wirklichen Server oder mit einem MITM sprichst. PFS schützt dich davor nicht.

Nuja, dann müsste man mir aber auch einen falschen Nameserver unterjubeln bzw. das DNS manipulieren... damit hätte ich dann noch ein ganz anderes Problem.
 
Schon mal in ein Wifi Netz eingeloggt, dass du nicht selber administrierst? MITM ist nicht nur ein theoretisches Angriffsszenario.
 
DocWindows schrieb:
Die haben das nicht nur gewusst, die haben das eingecheckt :evillol:

Das CIA und FBI dafür verantwortlich sind war auch mein erster Gedanke. ;)

blackshuck schrieb:
was heißt das jetzt für den laienhaften 0815 user wie ich einer bin? was kann/muss ich machen?
KaHaKa schrieb:
Wüsste ich auch gerne.

Wenn das System noch supported wird sollte bereits ein Update bereitstehen.
Ich habe gerade meine Ubuntu/Xubuntu Systeme inkl. des Ubuntu Server 12.04.4 LTS auf meinem Pandaboard aktualisiert und da waren OpenSSL und libssl Updates dabei.
Bei Debian, Ubuntu, etc. mit dem apt Paketmanager einfach das Terminal öffnen und folgende Befehle eingeben:
Code:
sudo apt-get update
sudo apt-get upgrade 
bzw. statt der Zeile mit dem upgrade ein dist-upgrade (siehe nächste Zeile)
sudo apt-get dist-upgrade

In der Regel ist das alles, außer dass ggf. aufgrund eines Updates (in der Regel bei Kernel-Updates) auch mal ein Neustart nötig ist.


Sofern hier Personen sind die keine automatischen Updates unter Ubuntu/Debian aktiviert haben, gibt es auch noch die folgenden Notifications wie hier (insbesondere für die Systeme ohne GUI sprich Server geeignet):
Code:
Welcome to Ubuntu 12.04.4 LTS (GNU/Linux 3.2.0-1444-omap4 armv7l)

 * Documentation:  https://help.ubuntu.com/

20 packages can be updated.
20 updates are security updates.

Die Meldung sieht man sobald man die Konsole öffnet bzw. sich per SSH einloggt (wie gesagt für Ubuntu/Debian und vermutlich auch andere Distributionen).
Die Installation erfolgt mit folgender Zeile:
Code:
sudo apt-get install -y update-notifier-common
Ergänzung ()

Daaron schrieb:
@iceview
Siehe Changelog der Pakete
Was mich da etwas schockiert ist "urgency=medium". Was ist dringender als ne Memory Disclosure in der Verschlüsselung?

DAS habe ich mich auch gerade gefragt.
 
Eine RCE z.b. ist schlimmer. Außerdem werden nur teile des RAMs geleakt. Also man braucht schon glück um an irgendwelche Schlüssel zu kommen.

Als der bug noch nirgends gefixt war, war das ziemlich interessant. Man hat halt die kompletten get/post/... requests mitsamt emails, passwörtern, ips, useragent etc. gesehen. Das womit der Server eben gerade arbeitet.
 
Sennin schrieb:
:
Mindfactory.de ist sogar jetzt noch betroffen :freak:

Seit dem Datendiebstahl vor längerer Zeit trau ich deren Sicherheit nicht weiter wie ich ein Klavier werfen kann. Die haben es bei einigen, Entschuldigung, verschissen bis in die Steinzeit.
 
DocWindows schrieb:
@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.

Zu deiner Frage(n):
Entdeckt haben die Lücke unabhängig von einander ein Team der finnischen Sicherheitsfirma Codenomicon und das Sicherheitsteam von Google.

Codenomicon ist aus einem Spin-off der University of Oulu hervorgegangen, um genauer zu sein der Oulu University Secure Programming Group (OUSPG), die ja vor allem im Bereich des Fuzzing (Robustness Testing / Negative Testing) sich einen Namen gemacht haben. In Deutschnland gibt es durchaus auch solche Projekte http://www.inf.h-brs.de/Forschung+_...jekte/Abgeschlossene+Projekte/SoftSCheck.html

Glaubst jetzt wirklich im ernst, dass sich Sicherheitsfirmen wie Codenomicon oder das Sicherheitsteam von Google sich nur mit Open Source beschäftigen. (Google Security Engineers Help Microsoft Patch Windows Flaws , Google Security Engineers Again Help Microsoft Fix Windows)

Selbstverständlich werden auch cloused source Systeme überprüft und das nicht nur im Rahmen irgendwelcher Hacking-Wettbewerb wie Pwn2Own*.

Und manchmal sind Fehler im Code so trivial, zumindest im nachhinein, dass man sich durchaus die Frage stellen kann, wie konnte so etwas nur passieren.
Beispielsweise die "goto fail" Panne bei Apple:

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
OSStatus err;
...

if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
...

fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;
}


Solche indirekten Unterstellungen wie: "mit closed source wäre das nicht passiert" sind einfach nur ....
Denn so gesehen müsste Windows, IE .. schon prinzipiell viel sicherer sein als die open source Konkurrenz.
Jetzt warte ich nur noch darauf, dass jemand schreibt meine Erfahrung der letzten 10 Jahre hat gezeigt, dass dem so ist. :freak:

Pwn2Own*

Das Google-Team hatte einen eindrucksvollen Angriff im Gepäck: Es gelang ihnen, einen Mac zu kompromittieren, indem darauf eine speziell präparierte Webseite mit Safari geöffnet wurde. Zur Demonstration startete beim Aufruf der Seite der Taschenrechner, das Google-Team hätte allerdings beliebigen Code mit Root-Rechten ausführen können. Google nutzte eine oder mehrere bislang unbekannte Schwachstellen für die Demonstration. Details wurden nicht bekannt, aber an Apple gemeldet. Das Team des Veranstalters hat einen mehrstufigen Angriff auf den Internet Explorer unter Windows demonstriert, der unter anderem einen Sandbox-Ausbruch umfasst. Welche Versionen angegriffen wurden, ist nicht bekannt.

Auch die Teilnehmer des Pwn2Own waren erfolgreich: Am ersten Tag gelang es drei Kontrahenten – darunter Vupen – Sicherheitslücken in Firefox auszunutzen, bis hin zum Einschleusen von Code. Vupen hat darüber hinaus in drei weiteren Kategorien abgeräumt – jeweils unter Windows 8.1: Im Adobe Reader und in Flash gelang der Sandbox-Ausbruch mit anschließendem Ausführen von Code, beim Internet Explorer 11 machte sich das Unternehmen einen Use-after-free-Fehler für einen Sandbox-Ausbruch zunutze.

So gelang es etwa dem chinesischen Keen Team sowohl Apple Safari als auch Adobe Flash über bislang unbekannte Schwachstellen zur Code-Ausführung zu bringen.

Das Team des Exploit-Brokers Vupen hat einen Rechner über Google Chrome kompromittiert; einschließlich Sandbox-Ausbruch.

Die angegriffenen Programmen liefen laut Teilnahmebedingungen jeweils in ihrer aktuellen Version auf einem vollständig gepatchten Windows 8.1 oder Mac OS X Mavericks. Wie immer wurden die Details über die bislang unbekannte Schwachstellen nicht veröffentlicht, sondern vertraulich an die jeweiligen Hersteller gemeldet.​
 
Ja, jeder kann (ist) davon betroffen sein.
Kurz: jede (Web-)Seite/Service die OpenSSL zum Verschlüssen nutzt und die entsprechende Version installiert hat, ist der Gefahr ausgesetzt. Und je nach Quelle sind das 2/3 aller Webseiten überhaupt. Von Onlinekaufhäusern über Banken und E-Mail anbieten bis hin zu Foren und Chats. Überall könnte man über die Lücke, Pins, Tans, Passwörter, (E-Mail) Adressen, Bankdaten etc. auslesen.
 
Zurück
Oben