Skip to content

Dann doch: Schwaches OpenSSL in Debian, Ubuntu & Co.

Nachdem mich mehrere Leser darauf angesprochen haben, dass ich es vielleicht doch noch bloggen soll (und nicht nur rummailen), habe ich mich dazu verleiten lassen.

Ich denke, dass die meisten das Thema eh schon kennen und behoben haben, wenn nicht, hier das Mailing, das wir an unsere Kunden verschickt haben:
Lieber Herr Mustermann,

wie Sie vielleicht in zahlreichen Sicherheitsforen oder auf den einschlägigen News-Tickern gelesen haben, gibt bzw. gab es ein Sicherheitsproblem in Debian- und davon abgeleiteten Linux-Distributionen.

Auslöser dieses Problems ist eine von den Debian-Entwicklern vorgenommene Ändeurng an OpenSSL, wovon wiederum viele weitere Dienste, insbesondere OpenSSH und Apache, abhängig sind.

Durch die Schwachstelle ist es für Angreifer möglich, Keys zu erraten, die von diesen Applikationen erzeugt wurden. Insbesondere betrifft dies SSH-Keys, die unter anderem zur passwortlosen Authentifikation genutzt werden können, oder Webserver-Zertifikaten.

Nochmals: Dieses Problem betrifft NUR Debian- und davon "abgeleitete" Systeme, insbesondere Ubuntu und Knoppix, und nur Zertifikate oder Keys, die auf diesen Systemen erzeugt wurden. Nutzer von Gentoo, Suse oder Fedora sind hiervon NICHT betroffen.

Sofern diese Sicherheitsmeldung für Sie zutrifft, lesen Sie bitte unbedingt die nachfolgenden Links:

[1] Debian-Sicherheitsankündigung via Mailingliste
[2] Schlüsselaustausch
[3] Debian-Sicherheitsankündigung 1571
[4] Testing keys with vulnkey
[5] Testing keys using dowkd.pl
[6] Schwache Krypto-Schlüssel unter Debian, Ubuntu und Co.

Bitte kontaktieren Sie im Zweifelsfall Ihren Administrator oder Ihre IT-Abteilung. Bitte haben Sie Verständnis dafür, dass wir aus rechtlichen und technischen Gründen nicht prüfen können, ob Sie diese Sicherheitsmeldung betrifft.
Nachtrag 16:47
Das Problem betrifft natürlich auch Anwender anderer Distributionen, wenn eingesetzte Keys auf einem verwundbaren System erzeugt wurden!

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Marc 'Zugschlus' Haber

Außerdem sind DSA-Keys für ssh kompromittiert worden, wenn sie mit einem gegen das schwache OpenSSL gelinkten Client auch nur benutzt wurden - auch wenn sie alt sind oder auf einem nicht schwachen System erzeugt wurden!

-thh

Gilt das nur für die Nutzung mit einem "schwachen" Client oder auch für die Nutzung mit einem Server - also von einem "intakten" Client aus -, bei dem das "schwache" OpenSSL genutzt wurde?

tt

Um den DSA zu knacken, muss der Client schlechte Zufallszahlen verwenden. Jede DSA-Operation benötigt eine sichere Zufallszahl. Kennt Eve die Zahl und den public key, kann sie den private key rekonstruieren.
Ohne die Zufallszahl zu kennen, kann Eve den Schlüssel auch trivial errechnen, wenn sie zwei signierte Nachrichten kennt, in die die selbe Nonce eingegangen ist.

So gesehen ist DSA deutlich schwieriger sauber zu implementieren als RSA. Unabhängig davon unterstützt DSA vernünftige Schlüssellängen bisher nur im FIPS Draft. Bis dieser zum Standard und implementiert wird, kanns noch dauern. -> Zwei gute Gründe auf DSA zu verzichten und nur RSA-Schlüssel zu verwenden. Wenn der erste vernünftige Quantenrechner gebaut wird, haben wir ja immer noch ECC - oder Quantenkrypto für alle :-)

Andy

Darf ich nun eine Doofe Frage dazu stellen?
Da meine NAS auch auf auf einem wenig getunetem Debian basiert.

Betrifft dies nur Keys die man zur Passwortlosen Authenfikation benutzt?
Das hab ich bei mir nämlich generell deaktiviert aus Sicherheitsgründen (nur weil einer an meinem Notebook sitzt, soll der nochnet auf die Server zugreifen können)
Auserdem is son 14 stelliges Passwort das auf zufälligen Zahlen und Buchstaben besteht... also sowas sollte man sich doch merken können. ;-)


Ansonsten muss ich erstmal schauen ob da auf dem System überhaupt die "Standart" OpenSSL Version läuft die bei Debian mitkommt, oder doch eine andere.

Marki

Was hat Dein NAS mit Deinem Notebook zu tun? Egal... ;)
Es ist egal ob Dein Private-Key verschlüsselt ist (ne Passphrase braucht) oder nicht.
Da man die "paar" schwachen privaten Keys vorberechnen kann, kann man sich damit natürlich auch direkt einloggen - ob Deine ganz persönliche Datei mit dem Private-Key verschlüsselt ist oder nicht interessiert da niemand ;)
Und die Passwort-Auth., naja... solang keiner Deinen Traffic abhört der vielleicht auf schwachen Host-Keys basiert, ist das vermutlich sicher(er), ja. Dennoch ist dann man-in-the-middle usw. möglich, falls jmd an der richtigen Stelle sitzt.
Von daher kann ich der letzten Zeile nur beistimmen, kuck Dir mal lieber genau an.

Andy

NAS wurde ursprünglich ausschlieslich angeschafft um mit dem Notebook darauf zuzugreifen ;-)
Ist auch heute noch der Hauptverwendungszweck :-)


Hab jetzt mal nachgesehen (was für ein Affenzirkus, hatte das Root Passwort vergessen...), scheint eine extrem modifizierte Version zu sein, wenn ich jetzt so auf den ganzen Seite nachlese ist die Sicherheitslücke anscheinend auf dieser Version nicht vorhanden.

Ich werd aber später mal selber mit einem anderem Rechner einfach ein "Worst Case Scenario" testen. Nur um sicher zu sein. Wiel soviel von Programmierung verstehe ich auch wieder nicht :-)

Trotzdem war die Warnung hier gut, ich geb zu ich hätte das sonst nicht gewusst.
Weil demnächst einer der beiden NAS Server auf ein "Normales Debian" umgerüstet wird von mir.
Die Images dafür hab ich bereits seit einigen Wochen rumliegen, werd jetzt nochmal alles neu zusammenstellen

Andy

Ach mist, sollte eine Antwort auf #2.1 werden :-)

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

BBCode-Formatierung erlaubt
Formular-Optionen