frage zum debian-openssl-bug

stimmt das? http://forum.golem.de/read.php?25056,1311313,1311313#msg-1311313?
ich kann das nicht glauben. zum einen wird für die schlüsselerzeugung ja sowieso /dev/random verwendet, zum anderen wäre das ja auch ein bug in openssl, wenn man sicherheitspatches für den linux kernel verwendet, die jede page mit 0 initialisieren, bevor sie einem programm zugeordnet wird.
sollte das wirklich das problem gewesen sein, so wäre das zum einen ein debian bug, weil eine distribution wieder code anderer pakete verändert hat, ohne das mit den entwicklern abzuklären, und zum anderen ein bug in openssl, weil man sowas echt nicht tun kann. das is wirklich sehr schlechter code.

darthdespotism

Zitat aus deinem Link:

Derjenige, der den Patch gebaut hat hatte sich aber vorher in der openssl Mailingliste erkundigt, ob das so OK ist und niemand hat Einwand erhoben:

mailinglisten reichen für sowas nicht aus. das ist nur eine alibi-aktion, damit man sagen kann, "ich bin nicht schuld. ich habe jahr die entwickler gefragt.". wenn distributionen was am code anderer pakete ändern, muss das direkt mit den entwicklern abgeklärt werden. vor allem, wenn es um so wichtige pakete geht.
dieser Ulf Möller scheint mit diesem code wohl nicht vertraut genug gewesen zu sein und ist außerdem kein mitglied des core developer teams laut openssl homepage. vielleicht wurde er auch falsch verstanden. das vorgehen der debian entwickler ist auf jeden fall nicht akzeptabel.

rüdiger

Ich hab den OpenSSL Code gerade mal etwas überflogen. Daher weiß ich nicht ob meine Vermutung zutrifft. Aber (was feststeht) der entsprechende Code MD_Update(&m,buf,j); wurde in static void ssleay_rand_add(const void *buf, int num, double add) auskommentiert. MD_Update scheint einfach weitere Entropie zum Seed in m hinzuzufügen. Wie man sieht, ist buf (also das Array mit der Entropie) auch der Parameter der Funktion ssleay_rand_add . Das ganze wird über RAND_SSLeay als "Methode" eines quasi Objektes zur Verfügung gestellt. Die Google-Code Suche nach RAND_SSLeay zeigt, dass das Interface an mehreren Stellen im Code benutzt wird um Entropie dem Seed zuzuführen. Vielleicht wurde an einer Stelle für zusätzliche Entropie einfach ein uninitialisierter Buffer hinzugefügt. Valgrind hat das eben in der add-Funktion moniert, da dort auf den Buffer zugegriffen wurde und der Entwickler hat als Resultat eben das MD_Update entfernt. Da die Funktion aber auch für das Hinzufügen anderer Entropie genutzt wurde, wurde so die Entropie im Seed drastisch verringert.

Ich hoffe, dass sowohl die Entwickler, als auch die Maintainer aus der Geschichte lernen.

rüdiger schrieb:

Ich hoffe, dass sowohl die Entwickler, als auch die Maintainer aus der Geschichte lernen.

Offensichtlich nicht, denn der "Fix" bestand darin die Stelle einfach wieder einzukommentieren

ja das war eigentlich nur ein problem mit den variablennamen, da die zwei MD_Update dinger genau gleich aussehen aber eine andere funktion haben. Bei einem ist einfach nur der uninitialisierte buffer dabei um die entropie noch zu verbessern, das andere ist aber eben notwendig um überhaupt entropie in den key zu bekommen.

Das resultat ist, dass auf 10000 versuche 100-erte ergebnisse 4-mal bei einem test vorkommen...

borg

olaf@pc:~$ ssh-vulnkey .ssh/id_rsa
COMPROMISED: 2048 76:97:18:7e:85:08:7d:42:53:49:5e:85:e6:3c:65:b2 .ssh/id_rsa.pub

omg, jetzt darf ich erstmal überall meine neuen public keys verteilen...

gibts denn schon nen angriff dafür, oder hat mal wer ausgerechnet wie schnell man mit den vorhandenen informationen einen brute-force angriff auf einen key ohne weitere informationen durchführen kann?

Achtet mal so am Rande auf die Jahreszahl:

Die erste betroffene Version war 0.9.8c-1, die am 17. September 2006 in den Unstable-Zweig der Distribution gelangte und von dort auch in die mittlerweile stabile Version 4.0 alias "Etch".

rüdiger

http://metasploit.com/users/hdm/tools/debian-openssl/

borg

rüdiger schrieb:

http://metasploit.com/users/hdm/tools/debian-openssl/

Q: How long did it take to generate these keys?
A: About two hours for the 1024-bit DSA and 2048-bit RSA keys for x86. I used 31 Xeon cores clocked at 2.33Ghz. I am generating the RSA 4096-bit keys now and the total time should be about 18 hours.

oh wow, das ging dann doch nen bisschen schneller als ich erwartet hätte. zum glück ist gpg nicht betroffen, ich glaube da wäre das geschreie riesig .

gentoo user schrieb:

scheint mit diesem code wohl nicht vertraut genug gewesen zu sein und ist außerdem kein mitglied des core developer teams laut openssl homepage. vielleicht wurde er auch falsch verstanden.

Es gab zwei Probleme: Kurt Roeckx sprach vom Debuggen von Anwendungen, nicht davon, dass er Debian patchen wollte, und er behauptete, dass "buf" in Zeile 247 ein uninitialisierter Buffer sei. Nun kenne ich tatsächlich nicht alle 625000 Zeilen auswendig, und da wirklich auch uninitialisierte Buffer in den Pool eingemischt werden und seine Mail wie eine allgemeine Diskussion zum Thema Entropie daherkam, habe ich keinen Grund gesehen, in den Programmcode zu schauen - und mich dafür ausgesprochen, die uninitialisierten Buffer beim Debuggen wegzulassen. Seine Behauptung war aber leider falsch; Zeile 247 ist die einzige Stelle, an der buf, das Argument von ssleay_rand_add(), überhaupt dereferenziert wird! Um das zu merken, muss man mit dem Code auch nicht besonders vertraut sein.

Wenn er den Grund seiner Anfrage erwähnt oder um eine Prüfung seines Patches gebeten hätte, hätte ich mir den Kontext angesehen und er hätte eine ganz andere Antwort bekommen. Dumm gelaufen. Das eigentliche Problem ist aber, dass Debian einzelne Personen sicherheitsrelevante Änderungen machen lässt, ohne dass die von irgendjemandem geprüft werden.

es zeigt, dass die kommunikation zwischen distributionen und maintainern verstärkt werden muss. die development mailinglisten sind dafür zu schwach. zu leicht gehen dort wichtige mails in der flut der anderen unter. das gilt nicht nur für openssl und debian. bei gentoo sieht man wie heftig es nötig ist, als stabil releasete pakete noch mal zu patchen. diese geschichte hier wird, ob wir wollen oder nicht, sehr negative auswirkungen auf open source haben. so ein schwerwiegender bug in einer sonst als sicher geltenden distribution in einem so extrem zentralen paket wird kaum einen guten eindruck hinterlassen. deshalb kann man die maintainer der distributionen und der pakete nur dringenst bitten, sich mehr um die kommunikation zu kümmern. vielfach ist leider das problem, dass sich die maintainer total vor vorschlägen von außen abschotten und nix wissen wollen. jeder andere kann nichts und die maintainer sind die götter auf der tastatur. sowas ist traurig.

nman

gentoo user schrieb:

jeder andere kann nichts und die maintainer sind die götter auf der tastatur. sowas ist traurig.

Irgendwie interpretierst Du da schon eine Menge hinein, meinst Du nicht?

http://blog.pas-un-geek-en-tant-que-tel.ch/archives/2008/05/13/Blind_trust_in_valgrind_-_the_Debian_OpenSSL_vulnerability/
weiß jemand genaueres über die vorwürfe gegen gnutls? sind sie berechtigt?

rüdiger

Was mich stört, dass die OpenSSL und Debian Leute sich hier versuchen gegenseitig etwas in die Schuhe zu schieben. Dabei sind eindeutig Fehler auf beiden Seiten passiert. Ich hoffe, dass die entsprechenden Konsequenzen auch auf beiden Seiten gezogen werden. Jetzt rumzustänkern bringt weder den OpenSSL, noch den Debian Leuten etwas.

gentoo user schrieb:

http://blog.pas-un-geek-en-tant-que-tel.ch/archives/2008/05/13/Blind_trust_in_valgrind_-_the_Debian_OpenSSL_vulnerability/
weiß jemand genaueres über die vorwürfe gegen gnutls? sind sie berechtigt?

Der Artikel ist absoluter Blödsinn. Fängt damit an, dass er das Problem falsch darstellt und die Vorwürfe gegenüber gnutls sind lächerlich. gnutls benutzt libgcrypt, was von gnupg abstammt und somit eine sehr lange Geschichte hat.

mal zuum thema passend: http://xkcd.com/424/

rüdiger schrieb:

Was mich stört, dass die OpenSSL und Debian Leute sich hier versuchen gegenseitig etwas in die Schuhe zu schieben. Dabei sind eindeutig Fehler auf beiden Seiten passiert. Ich hoffe, dass die entsprechenden Konsequenzen auch auf beiden Seiten gezogen werden. Jetzt rumzustänkern bringt weder den OpenSSL, noch den Debian Leuten etwas.

endlich jemand, der meiner meinung ist.

rüdiger schrieb:

Der Artikel ist absoluter Blödsinn. Fängt damit an, dass er das Problem falsch darstellt und die Vorwürfe gegenüber gnutls sind lächerlich. gnutls benutzt libgcrypt, was von gnupg abstammt und somit eine sehr lange Geschichte hat.

seh ich auch so. vor allem ist das problem, dass timing attacks wohl auf einem pc kaum realistisch sind. es gibt viel zu viele faktoren, die die ausführungsgeschwindigkeit einer funktion beeinflussen. sowas verwendet man bei smart cards. ein anderes argument ist, dass der chefentwickler von gnutls mathematiker ist, also genau das, was in diesem blog eintrag gefordert wird.