debian ssl-zertifikate viel zu schwach
hi!
jeder der einen debian (oder ubuntu) server betreibt sollte schnellstens openssl updaten und _alle_ zertifikate neu generieren.
http://metasploit.com/users/hdm/tools/debian-openssl/
//richard
p.s: und sich überlegen ob er debian wirklich noch vertrauen soll...
There are two factions of CS, the ones that hate computers, and the ones that hate science.
Hallo,
ich weiss ja nicht, wie das bei Debian ist, aber bei Ubuntu sind die neuen Versionen schon raus.
Und das neugenerieren der Schlüssel übernimmt er auch gleich beim Update mit.
Gruß
Thomas
Im Prinzip müssen alle Zertifikate, die auf Debian-Systemen generiert wurden neu erstellt werden. Indirekt sind dann auch andere Distris "betroffen", wenn sich z.B. die Leute mit einem der schwachen keys anmelden.
So einfach ist es dann doch nicht... Ich denke mal eher der Bug ist der absolute Supergau!
hi!
nur als kleiner hinweis:
_jedes_ ssl-zertifikat (ssh, https, openvpn, etc..), das in den letzten zwei jahren mit der openssl-version von debian erstellt wurde kann in der praxis angegriffen werden.
das ist keine lücke, die einfach durch das einspielen eines patches behoben werden kann.
//richard
There are two factions of CS, the ones that hate computers, and the ones that hate science.
Das heißt auch, sämtliche Internet-Transaktionen per https waren und sind unsicher, da die meisten Webserver auf Linux und auf Debian laufen?
Freude.
Oder wird hier bloß heiß gekocht, weil es mal nur 90 statt 99% sicher ist? (Wen juckt das außer die ganzen übereifrigen, sicherheitsfanatischen Admins? Wer nutzt das dann wirklich aus?)
Nochmal:
Bei mir hat er mit der Installation der Updates das Neugenerieren der Schlüssel gleich angestoßen.
Ich brauchte nur zu Bestätigen, dass ich die Schlüssel neu generieren will.
hi!
das betrifft nur debian (und die debian-basierenden distributionen).
und die sicherheit ist jetzt nicht von 99% auf 90% runter, sonder auf 0%.
auf dem von mir geposteten link finden sich _alle_ möglichen keys, die das debian-openssl erstellen kann.
das sind nur 32768 pro möglicher keylänge. die kann man in ein paar stunden alle durchtesten und schon hat man gewonnen.
//richard
There are two factions of CS, the ones that hate computers, and the ones that hate science.
wir reden hier aber nicht nur von mini-servern mit einem ssh-zertifikat, das man schnell tauschen kann.Zitat von shogun
es gibt auch leute, die betreiben certificate authorities, die müsse _alle_ zertifikate zurückrufen. (stichwort vpn-server)
//richard
There are two factions of CS, the ones that hate computers, and the ones that hate science.
AFAIK sind das nur Hashes, nicht die kompletten Keys.
1)alice iBook 12" G4 2)bob RaW 3)sam XBOX 4)foo NSLU2/Server(1) 5)bar Thinkpad T21/Server(2) 6)doh Thinclient 7)kim1 WGT634U 8)kim2 WL500G 9)kim3 WGT634U 10)amy Produktivserver im RZ 11)yui Produktivserver (2) im RZ 12)kaja wlan-Handy
und was ist mit all den authorized_keys, die Debian-User auf ihren Root-Servern, in VPN-Gateways, https-Zertifikaten, ... eingetragen haben? Die müssen auch alle neu generiert und verteilt werden.
Hier hat ein Bekannter von mir das recht anschaulich zusammengefasst...
Ich bin root - ich darf das.
Nur mal so als kleines Beisiel, wann es wirlich eklig wird.
Ein Arbeitskollege von mir hat Zugriff auf einen Cluster, auf welchem er "Molecular Modelling" betreiben kann.
Die Anzahl der Kisten im Cluster liegt IIRC im Bereich mehrerer hundert Kisten, auf allen läuft Debian und jeder der wahrscheinliche mehreren Tausend berechtigten User greift via SSH zu.
In der Haut des/der Admins, die nun sehr wahrscheinlich mehrere Tausend Keys neu erstellen und an _alle_ berechtigten User verteilen dürfen/müssen (und davon sind sicher nicht alle "IT-affin", also kann man sich die Masse der "Beschwerdemails" a la "Hilfe mein Login geht auf einmal nicht mehr" schon in etwa vorstellen) will ich jedenfalls nicht stecken.
Naja, das ist ja nur eine reine Fleißarbeit :-)
Viel interessanter ist herauszufinden, wie viele böse Menschen es durch den bereits verfügbaren Exploit geschafft haben, sich einen gratis-Account auf div. Servern zu holen?
Oder VPN-Gateways von Firmen, die evtl. Zugriff auf sensible Geschäftsdaten preisgegeben haben, weil sich jeder Yogi mit einem bel. PC am VPN anmelden konnte?
Für mich wäre die Meldung ein guter Grund, erst mal jeden Debianrechner in meiner Umgebung herunterzufahren und einem ausgiebigen Security-Audit zu unterziehen.
Wenn man dann noch überlegt, was denn alles von Debian und *buntu geforkt ist - kann einem ernsthaft schlecht werden...
Ich bin root - ich darf das.
Habe ich gestern auch gelesen... hammerhart.
Das ist wohl in der Tat des Security-Super-GAU des Jahres. Es ist mir ehrlich gesagt aber auch wirklich unbegreiflich wie man mal eben so, offensichtlich ohne Plan was man tut, an Paketen herumpatchen kann. Allerdings war ich auch noch nie ein Freund der Art und Weise wie Debian ( und damit indirekt oder direkt auch Ubuntu ) an Paketen herumbastelt.
Bei mir hat Debian mittlerweile jeglichen Kredit verspielt. Erst gibt es 2005 wochenlang niemanden der sich um Sicherheitspatches kümmert und dann wird einfach so an kritischen Paketen herumgespielt.
@ marce: Danke für den Link, das Problem wird dort sehr schön und verständlich erläutert.
@ Dobodo: Das ist eine der krassesten Lücken in letzter Zeit und um das so einzuschätzen muss man kein "übereifriger, sicherheitsfanatischer Admin" sein! Das ist nicht mal eben so eine theoretische Lücke ohne großartige praktische Auswirkungen sondern das betrifft tausende Systeme. Wenn man wie du ganz offensichtlich keine Ahnung hat wovon man redet sollte man sich informieren oder den Rand halten!
@ Rain_Maker: Der Admin wird seinen Spass haben... Bei der Gelegenheit fällt mir gerade auf dass es wohl etliche Unis im Land gibt mit Servern auf Debian-/Ubuntu-Basis. Hab eben mal nachgeschaut, an meiner wird zum Glück OpenSuse bzw. Fedora genutzt...
-hanky-
85.214.20.141 - Anti-Zensur-DNS-Server (FoeBuD)
"Die Nicht-Lösung eines nicht existierenden Problems" - Ron Gonggrijp über Wahlmaschinen
ACK.
Das Problem dürfte hier auch eher auf der anderen Seite liegen (bzw. sitzen *g*), zumindest weiß ich recht sicher, daß die Struktur auf Clientseite da sehr viel heterogener als "normal" (aka >= 95% sind Windowskisten auf denen dann putty läuft) ist.
Wenn man das also irgendwie automatisiert, im Sinne von $USER loggt sich via $SSH-CLIENT seines $BETRIEBSSYSTEMS ein und es wird automatisch ein neuer Key angeboten, der abgenickt werden muss, dann muss da eben etwas mehr als nur Putty berücksichtigt werden.
Aber auch das ist natürlich nur Fleißarbeit.
Von eventuellem Fehlverhalten von $USER jetzt mal ganz abgesehen (aka "Meldungen des Systems werden nicht gelesen und vor allem auch mit einem beherzten Klick auf Abbrechen quittiert"), aber OK, das ist dann ne andere Geschichte ....
*AUTSCH*
(Bis vor kurzem konnte man zumindest noch zu recht behauten, daß ein mit PubKey gesicherter SSH-Zugriff kein potentielles Einfallstor darstellt, das relativiert sich natürlich jetzt gewaltig.)
*AUTSCH²*
So langsam werden die Ausmaße etwas deutlicher; ich habe mir gestern mal mit meinen recht beschränkten Kenntnissen der Materie nur ein paar Minütchen überlegt, was jetzt so alles anstehen könnte.
Ehrlicherweise auf alles, was hier schon steht, bin ich auch nicht gekommen, und ich bin mir fast sicher, daß das eine oder andere Szenario bisher vergessen wurde, aber schon die paar "ekligen Gemeinheiten", die mir so spontan eingefallen sind, haben zu leichter Übelkeit geführt.
Nett auch (das fiel mir so spontan ein)
Man loggt sich auf $ONLINESHOP via https ein um seinen Warenkorb zu füllen usw. usf. ... (das Übliche halt).
Der "man-in-the-middle" hat dann unter Umständen grossen "SCHABSS" daran, mal den halben Katalog zu bestellen und das Theater, das auf den Kunden zukommt, dürfte nicht gerade gut fürs Herz und die Nerven sein.
Das ist zwar purer "Online-Vandalismus" ohne grossen eigenen Nutzen für den Angreifer, aber bei (D)DoS hat sich das ja auch "bewährt".
Jepp, könnte sein, daß Pillen gegen Reisekrankheit in nächster Zeit guten Absatz finden .....
@-hanky-
Bei uns an der Uni ist in dem Fall "zum Glück" auch auf Linux-Clientseite Fedora Standard, ein paar der für mich interessanten Server laufen auf RH, also Schwein gehabt.
Greetz,
RM
Berechtigungen
Lesezeichen