Hallo,
also auf
Heise gibts dazu einen Nachtrag:
Doch anstatt die konkreten Funktionsaufrufe für den unbelegten Speicherbereich zu entfernen, nahm der "Bugfix" laut Laurie der untergeordneten Funktion ssleay_rand_add() jede Möglichkeit, Daten in den Entropie-Pool zu übernehmen. Unbelegter Arbeitsspeicher ist dafür allerdings nur eine von mehreren möglichen Quellen.
Die Folge war, dass das Debian-OpenSSL nur noch die unter Linux 16 Bit lange Linux Prozess-ID für Zufallszahlen heranzog. Dies macht damit erstellte SSH- und SSL/TLS-Schlüssel mit einem einfachen Brute-Force-Angriff erratbar.
[..]
Bei den X.509-Zertifikaten für SSL und TLS ist die Situation hingegen noch unklar.
Da kommt ja freude auf, wenn man nur 2^16 Prozessids testen muss, um den private key herauszufinden.
Da sind die oben beschriebenen möglichen Auswirkungen wirklich katastrophal, einen 4096 Bit Key auf effektiv 16 Bit zu reduzieren schaffen nicht mal die Leute bei der NSA
Und da dies SSH keys, SSL keys und OpenVPN keys einschließt, auf dessen Kanäle extrem sensible Daten gesendet werden, ist dies schon eine Katastrophe. Der normale Mensch hat jetzt nicht soviele super sensible Daten, wenn aber irgendwelche Patientendaten per OpenVPN übermittelt wurden...
Wobei man jedoch sagen muss, dass diese Listenstruktur sehr verwirrend ist. Jedoch ist nach dieser Aussage der Patch an sich nie eingesendet worden.
Jedoch liegt die Schuld nicht allein an Debian sondern auch an diesen Kommunikationsproblemen.
Persönlich sehe ich eher eine geringer Schuld beim OpenSSL Team.
Ich finde man sollte bei extrem sicherheitskritischen Sachen die Finger weglassen und es den Leuten mit dem entsprechenden Know-How überlassen, also den entsprechenden Entwicklern. Wenn jeder in solchen Programmen rumspielt, ist es kein Wunder, dass es irgendwann jemand verschlimmbessert, einfach aufgrund von mangeldem Know How.
What I currently see as best option is to actually comment out
those 2 lines of code [die auf uninitialisierten Speicher zugreifen). But I have no idea what effect this
really has on the RNG. The only effect I see is that the pool
might receive less entropy.
Openssl-dev
Wenn man halbwegs Ahnung von der Materie hat und zusätzlich noch ausreichend Paranoid ist, was jeder sein sollte, der auf dem Gebiet irgendwie arbeitet, der weiß, dass allein schon der letzte Satz ein No-Go für die Änderung gewesen wäre.
Ein gutes Paper über Zufallsgeneratoren ist
Cryptanalytic Attacks on Pseudorandom Number Generators.
Wie man dem Entnehmen kann, ist das größte Problem von Zufallsgeneratoren eine gute Seed zu erhalten, also ein möglichst großen (guten) entropy pool.
Wenn man schon ahnt, dass eine Änderung diesen pool beeinträchtigen könnte, sollte man auf alle Fälle die Finger davon lassen. Man kann jede Entropy gebrauchen die man bekommen kann.
Dann finde ich es sehr dumm nur aufgrund einer Warnung von irgend so einem Tool zum Code-Check diese Zeile auszukommentieren.
Wenn man schon weiß, dass der Zugriff auf uninitialisierten Speicher _kein_ Fehler ist sondern gewollt da eingebaut ist, wie kommt man dann bitte auf die Idee, dieses auszukommentieren, nur damit dieses blöde Tool nicht mehr meckert? Besonders wenn man schon ahnt, dass dadurch der entropy pool verkleinert werden könnte...
Das ist in meinen Augen schon grob fahrlässig und da hat evt. jmd. nicht seinen Menschenverstand eingesetzt sonder stumpf nach dem Schema "Hauptsache keine Warnungen mehr erhalten" vorgegangen.
Es sollte jedem bewusst sein, dass Programme/Tools extrem dumm sind und einfach nach vorgegebenen Schema handeln. Die Bewertung jeder einzelnen Meldung muss dennoch weiterhin dem Menschen überlassen bleiben und dieser sollte auch mal die ein oder andere Warnung ignorieren.
Und wenn man sich die Antworten auf der
Mailingliste anguckt,sieht man, dass das keine Antwort das Vorhaben wirklich bestätigt.
Die einzige verwertbare Antwort von Ulf Möller:
" If it helps with debugging, I'm in favor of removing them."
Wobei man sagen muss, dass Ulf Möller aus dem development team stammt und nicht aus dem core team, deswegen vermutlich nicht sehr vertraut mit der entsprechenden Passage ist.
Bei Änderungen an höchst sensiblen Stellen sollte man sich schon das Okay von den core entwicklern holen und nicht darauf vertrauen, was irgendwelche Leute sagen, die Anwendungen für OpenSSL schreiben.
Und dass man als Core-Entwickler nicht die Möglichkeit hat, alle Einträge auf der development Liste zu lesen, sollte klar sein. Man rechnet auch nicht damit, dass Änderungen an OpenSSL auf der Development Liste besprochen werden.
PS:
An solch einem Fehler sieht man mal wieder, wie praktisch Systeme mit
Perfect Forward/backward Secrecy, wie z.B. Diffie-Hellman, sind.
![[HaBo]](/styles/default/logoklein.png)
