[Debian] Krypto-Keys unsicher (update)

Schlimme Sache! Besonders der Aufwand die ganzen Keys neu zu erstellen...! Richtig schlimm wäre es wenn sowas bei GnuPG passieren würde, da geht das austauschen von Keys ja nicht...
 
Nachdem ich mich ein bisschen in die Entstehung eingelesen habe, finde ich es einfach nur krass, wie das Ding zustande kam.

Was Heise im Link als Unbedenklichkeitsbescheinigung bezeichnet, ist der schnelle Kommentar, für Debuggig sei das sicher hilfreich.

Die Anfrage war:
"When debbuging applications ... it can show alot of warnings ... the following 2 pieces of code ...
What do you people think about removing those 2 lines of code?"

Die einzige Antwort, die einigermaßen zustimmend war:
"If it helps with debugging, I'm in favor of removing them."

Daraufhin wurde das entgegen Bedenken im Debian Bugtracker committet und released.
Der Patch ging nicht in den Upstream. Dadurch hatte OpenSSL keine Möglichkeit, das zu entdecken.

Und das schlimme: von den beiden Zeilen (die identisch aussahen) erzeugte nur eine die Valgrind-Meldung und die andere sah eben nur identisch aus. Ihre Entfernung hat dann leider den GAU verursacht.

Und ich halte es durchaus für einen Debian-hausgemachten Fehler. Meine Meinung ist ja, dass dieser Patch durch den Upstream hätte gehen müssen, bevor er in das Release gekommen wäre - oder auch nicht. Denn auf dem Wege wäre aufgefallen, dass es den PRNG quasi komplett kaputt gemacht hat.
 
Das sowas passieren kann, gut damit kann ich mich eigentlich in gewisser Weise noch abfinden. Man kann nicht davon ausgehen, dass jeder Programmierer sofort den Quelltext von einem anderen Programmierer versteht. Allerdings stellt sich die Frage: "Sollte ein Programmierer den Quelltext verändern, wenn er ihn nicht versteht und das ganze dann an tausende Benutzer ausgeben?"

Noch viel schlimmer ist, dass dieser Fehler 2 Jahre lang einfach nicht bemerkt worden ist. Da frag ich mich, wie das bei der Philosophie von Debian passieren kann. Angeblich muss jedes Paket eine lange Erprobungsphase bestehen, bis es released wird.

Ich war bisher auch der Meinung, dass die Distributoren, die Pakete verändern müssen, damit sie sie auf das jeweilige System anpassen können. Aber ich bin davon ausgeganen, dass diese so verändert werden, dass sie ihre Funktion noch vollständig gegeben ist.

Man muss sich mal überlegen, was das z.B. für CaCert bedeudet. Ich geh mal stark davon aus, dass die auf OpenSSL gesetzt haben.

Davon mal abgesehn ist es jetzt passiert, der Fehler wurde entdeckt und die Admins müssen jetzt reagieren. Bedeudet halt etwas Arbeit. Typischerweise hat man selbst erstellte Zertifikate eh nur selbst in Verwendung, z.B. für SSH. Zertifikate für Webseiten sind meistens von einer öffentlichen Stelle. Von daher dürfte es sich für die größte Anzahl von Admins in Grenzen halten.

Genau hier fand ich die Reaktion von Strato positiv. Diese Email hat wirklich jeden Stratokunden erreicht. Wenn jetzt jemand nicht aufwacht is er selber schuld. :-)
 
Vielleicht ist das gar nicht schlecht, Admins die Ihre Server ein wenig vernachlässigt haben in letzter Zeit sollten jetzt wieder wach sein, und vielleicht ein wenig aufmerksamer sein.
 
Ganz ehrlich traced, daran glaub ich nicht!
Wer bisher nicht wachsam war, wird es auch weiterhin nicht sein.
Warum auch? 2 Jahre funktionierten die Schlüssel, warum sollten sie nicht weitere 2 Jahre funktionieren?

Ich hab übrigens ne wirkliche sch*** lange Zeit damit verbracht auf allen Kunden-Server meine neuen Schlüssel einzuspielen... :(

huschi.
 
Sind die Zertifizierungsstellen eigtl. auch hiervon betroffen? Ich habe zum Glück nur SuSe Keys...

--marneus
 
Bei den großen wie Thawte ist nichts zu erkennen. Ich glaub auch nicht, dass die auf OpenSSL setzen.

Anders bei CaCert. Die sind aber auch nicht betroffen, da das Root-Zertifikat bereits älter als 2 Jahre ist. Die hatten nur intern damit Probleme:
Regarding the recently discovered random number vulnerability:CAcert's root keys are not affected, since they were created before the bug existed.
Click to expand...
 
@Phate
Selbst wenn sie OpenSSL einsetzen, heißt das noch nicht das sie betroffen sind. ;)
Sie müssten schon die OpenSSL Version von Debian nehmen.

Alle anderen sind nicht betroffen. ;)
 
Meistens ist es ja so, dass für die Zertifikatsverwaltung etablierte Systeme verwendet werden, die sich besonders durch Sicherheits auszeichnene (OpenBSD) oder eigene Systeme (Alternativen zu OpenSSL, Kryptobeschleuniger, externe PRNGs) von daher halte ich es auch für ausgeschlossen, dass Root-Zertifikate ausgetauscht werden müssen. Ansonsten wäre das eine wirtschaftliche Katastrophe.

Soll aber nicht heißen, dass darum überhaupt kein Zertifikat von Thawte, CACert usw. ausgetauscht werden muss - die Schlüssel für die Zertifikate werden Lokal erzeugt ;-)
 
elias5000 said:
Nach der Sache bin ich mal wieder extremst froh, Debian nicht gut zu finden und deshalb nicht in der Fraktion derer zu sein, die das betrifft. (SCNR)
Click to expand...

Nicht nur Debian-Admins sollten sich Gedanken machen.

http://www.heise.de/security/Der-kleine-OpenSSL-Wegweiser--/artikel/108001 said:
Obwohl nur Debian-Derivate unsichere Schlüssel erzeugen, sind auch Systeme anderer Hersteller angreifbar, wenn beispielsweise ein Debian-User dort einen Schlüssel von seinem Debian-System für den Login freigegeben hat. Ist etwa auf einem Suse-Linux-Server in der Datei ~/.ssh/authorized_keys ein verwundbarer Schlüssel aufgelistet, hat der Suse-Admin ein Problem.
Click to expand...
 
fuchzga said:
Nicht nur Debian-Admins sollten sich Gedanken machen.
Click to expand...
Natürlich nicht. Aber der einzige unter Debian erzeugte Key war schnell ersetzt. :cool:

Ich bin immer noch entsetzt über die Sache. Was ich überhaupt nicht begreife ist, dass es dazu noch ein Posting an openssl-dev gegeben hat, in dem der Contributor des Patches die Annahme äußerte, dass mit seinem Patch weniger Entropie in den PRNG einfließen wird.
Alleine das hätte den Patch schon verboten, selbst wenn es den Schlüsselraum nicht so extrem beschnitten hätte. In der Kryptografie zählt nur das maximal erreichbare - auch nur ein bisschen weniger gilt schon als kompromittiert.
 
@Firewire2002
im Fall von CACert bin ich davon ausgegangen, dass dort Debian eingesetzt wird, da sie schreiben, dass das Root-Zertifikat älter als 2 Jahre ist und von daher nicht betroffen. Sollte dem nicht der Fall sein, hätten sie ja einfach schreiben können: Wir benutzen nicht Debian und deswegen ist es uns egal.



Ubuntu hat das meiner Meinung nach recht nett gelöst. Die haben zwar einen Tag länger für ihr Update gebraucht, aber dafür hat der Updater alle Keys automatisch neu erzeugt. Das hat auf meinem Debian-Server nicht so gut geklappt.
 
Phate said:
hat der Updater alle Keys automatisch neu erzeugt. Das hat auf meinem Debian-Server nicht so gut geklappt.
Click to expand...
Bei mir wurden alle Server-Keys der Debian-Server ohne Handanlegen neu erstellt.
Ubuntu hatte eine leicht verwirrende Aussage auf den Desktop gebracht. War etwas verwirrend, wenn man die Zusammenhänge nicht kannte (fand ich).

huschi.
 
Hallo!
Das ist das Home Verzeichnis des jeweiligen Benutzers. Für den Systembenutzer test also normalerweise die Datei home/test/.ssh/known_hosts.

mfG
Thorsten
 
You must log in or register to reply here.
Back
Top