libssl - Debian
Bernd Kreuss
Ringen um die richtigen Worte bzw. vollkommene Sprachlosigkeit, welche
dieses nunmehr schon mehrere Tage währende (fast schon gespenstische)
Schweigen hervorruft, angesichts des größten denkbaren Unfalles in der
Geschichte der modernen Kryptographie?
Fragt sich
Bernd
--
private communication within hostile networks:
http://torchat.googlecode.com/
Arno Welzel
> Stimmt etwas mit meinem Newsreader nicht oder ist das immer noch das
> Ringen um die richtigen Worte bzw. vollkommene Sprachlosigkeit, welche
> dieses nunmehr schon mehrere Tage währende (fast schon gespenstische)
> Schweigen hervorruft, angesichts des größten denkbaren Unfalles in der
> Geschichte der modernen Kryptographie?
Jeder dürfte mittlerweile mitbekommen haben, worum es geht. Wozu dann
noch hier explizit erwähnen?
Juergen P. Meier
> Stimmt etwas mit meinem Newsreader nicht oder ist das immer noch das
> Ringen um die richtigen Worte bzw. vollkommene Sprachlosigkeit, welche
> dieses nunmehr schon mehrere Tage währende (fast schon gespenstische)
> Schweigen hervorruft, angesichts des größten denkbaren Unfalles in der
> Geschichte der modernen Kryptographie?
Es betrifft nur Debian >= 4.0 Systeme, auf denen Schluesselmaterial
(insb. DSA aber auch RSA schluessel) mittls OpenSSL (libssl/libcrypto)
zwischen 2006 und letzte Woche erstellt wurde.
Ich musste zwei DNSSEC Zonen-keys wegwerfen und einen SSH-key neu machen,
die CA/RA meiner PKI laeuft nicht unter Debian.
Das Grosse Kino findet wohl ausserhalb von dcsm statt.
Juergen P. Meier
> Jeder dürfte mittlerweile mitbekommen haben, worum es geht. Wozu dann
> noch hier explizit erwähnen?
Man koennte noch den anderen Quellen/Diskussionen und offiziellen
Webforen hinzufuegen, dass auch DNSSEC Keys kompromitiert sind, die
mit Hilfe von dnssec-keygen auf Debian Systemen erstellt wurden.
Nur fuer den Fall...
Lutz Donnerhacke
> Man koennte noch den anderen Quellen/Diskussionen und offiziellen
> Webforen hinzufuegen, dass auch DNSSEC Keys kompromitiert sind, die
> mit Hilfe von dnssec-keygen auf Debian Systemen erstellt wurden.
Ja, die, die ich als angreifbar verifiziert habe, sind benachrichtigt.
Bernd Kreuss
> Jeder dürfte mittlerweile mitbekommen haben, worum es geht. Wozu dann
> noch hier explizit erwähnen?
Das bezweifle ich, das das jeder mitbekommen hat. Erwähnen könnte man es
vielleicht weil das hier dcsm ist (oder mal war?). Vor allem was die
Konsequenzen, auch die indireketen angeht.
- Was ist mit aufgezeichneten SSH-Sitzungen (welchen Einfluss hat der
host key auf die Sitzungsschlüssel) Ist es FUD? Wenn nein, warum nicht?
Was ist z.B. der Einfluss auf einen aufgezeichnete Diffie-Hellman-
Schlüsseltausch? Beide varianten, Alice->Bob oder Bob->Alice (Alice hat
Debian, Bob nicht)
- Was ist mit Tor-Hidden-Service-Keys? (Es gibt brute force tools für die
Generierung von .onion adressen die im Ergebnis eine bestimmte RegExp
matchen sollen, warum haben die in den letzten 2 Jahren *nicht* um
Größenordnungen besser funktioniert als in der Theorie zu erwarten
gewesen wäre, obwohl sie angeblich(?) auch schwach sind?) Ist es FUD?
Wenn nein, warum nicht?
- Warum wird mancherorts geschrieben, auch gute Schlüssel, die in
irgendwelchen SSH(?) SSL(?) Whatever(?) Verbindungen mit betroffenen
Hosts zum Einsatz kamem seien ebenfals als kompromittiert zu betrachten?
Warum? welche Mechanismen greifen hier?
- Welche anderen, nicht so offensichtlichen Implikationen ergeben sich,
und warum?
- Welche anderen zunächst befürchteten Konsequenzen erweisen sich bei
genauerem Hinsehen als nicht gegeben, und warum?
Das sind alles Fragen, die ich so verstreut über die letzten Tage
aufgesammelt habe, die Antworten darauf verweisen oftmals auf Mutmaßungen
oder pauschale "tausch im Zweifel alle Schlüssel aus!"
Natürlich kann ich im Zweifel alle Schlüssel austauschen. Dann weiß ich
zwar, dass ich in Zukunft wieder "sicher" bin, aber ich habe immer noch
kein Bild über den *genauen* Zustand vor dem Austausch, bzw. den
tatsächlich eingetretenen Schaden, oder vielleich auch den im Einzelfall
eben glücklicherweise (oder mathematischerweise) doch *nicht*
eingetretenen Schaden.
Da ist denke ich mal genug Stoff für einige Diskussionen gegeben.
Michael Ströder
> Man muss sich das mal vorstellen.
> Da fragt ein Debian-Maintainer auf einer OpenSSL-Mailingliste nach, was die
> Speicherzugriffe auf nicht initialisierte Abschnitte sollen, er bekaeme da
> Probleme mit dem Debuggen. Er gibt sich hier nicht als Maintainer zu erkennen.
> Aus der lapidaren Antwort: "If it helps with debugging, I'm in favor of removing
> them." wird geschlossen, dass sie unnoetig sind, er entfernt sie ohne zu
> verstehen was sie eigentlich machen und pflegt die Aenderungen in das stable
> release ein. Es gibt scheinbar keine weitere Qualitaetskontrolle, weder erfolgt
> eine Rueckgabe der Aenderungen an OpenSSL.
Ich verstehe auch nicht so recht, welche Definiton das Debian-Projekt
von "stable" hat. Es gibt mehrere Open-Source-Projekte, wo ich den
Einsatz der Debian-Pakete explizit nicht empfehle, da massiv drin
rumgepatcht wurde.
Teils sicherheitsrelevante Beispiele:
1. OpenLDAP mit GnuTLS statt OpenSSL führt immer wieder zu massiven
Problemen,
2. python-ldap wurde massiv rückwärts gepatcht, um noch mit OpenLDAP 2.1
gebaut werden zu können, obwohl ich das explizit vom Support
ausgeschlossen habe. Da verändert sich sogar das API.
> Das kann doch wohl nicht wahr sein. Ich will jetzt dem Maintainer nicht die
> einzige Schuld geben, er hat ja im guten Gewissen gehandelt.
Ich persönlich unterstelle da erst mal keine böse Absichten.
> Warum ging dieser "Bugfix" nicht zurueck an die Entwickler? Spaetestens hier
> waere der Fehler wohl aufgefallen...
Einige Distributoren, und eben auch das so viel als "stable" gerühmte
Debian, haben zu selbstständige Package-Maintainer, die sich zu wenig
mit den Upstream-Code-Entwicklern absprechen.
> Mein Vertrauen in Software ohne finanziellen Hintergrund ist nun mehr endgueltig
> erschoepft.
Meiner Erfahrung nach hat so was nix mit kommerziell vs.
nicht-kommerziell zu tun. OpenSSL ist in sehr vielen kommerziellen
Produkten eingebaut. Nur bekommt man nach einem Security Advisory für
OpenSSL nicht immer ein Security Advisory der ganzen kommerziellen
Produkthersteller. Bei manchen klappt's, die Masse der Hersteller
kümmert sich nicht drum.
> Sun&Co haben sehr wohl ihre Berechtigung.
Sorry, Du bist IMO naiv.
Ciao, Michael.
Thorsten Tüllmann
Michael Ströder schrieb:
> 1. OpenLDAP mit GnuTLS statt OpenSSL führt immer wieder zu massiven
> Problemen,
> 2. python-ldap wurde massiv rückwärts gepatcht, um noch mit OpenLDAP 2.1
> gebaut werden zu können, obwohl ich das explizit vom Support
> ausgeschlossen habe. Da verändert sich sogar das API.
Hatte 1. eigentlich irgendeinen vernuenftigen Grund? Ich vermute ja mal
ins Blaue, dass den Policy Lawyers die OpenSSL-Lizenz ein Dorn im Auge ist.
Ein "this will break existing setups" beim Upgrade auf lenny waere schon
angemessen...
ciao,
Thorsten
Michael Ströder
>
> Michael Ströder schrieb:
>> 1. OpenLDAP mit GnuTLS statt OpenSSL führt immer wieder zu massiven
>> Problemen,
>> 2. python-ldap wurde massiv rückwärts gepatcht, um noch mit OpenLDAP 2.1
>> gebaut werden zu können, obwohl ich das explizit vom Support
>> ausgeschlossen habe. Da verändert sich sogar das API.
>
> Hatte 1. eigentlich irgendeinen vernuenftigen Grund?
"Vernünftig" ist ja ein dehnbarer Begriff.
> Ich vermute ja mal ins Blaue, dass den Policy Lawyers die
> OpenSSL-Lizenz ein Dorn im Auge ist.
Jepp, genau das.
Aber viel beunruhigender finde ich das hier:
http://www.openldap.org/lists/openldap-devel/200802/msg00072.html
Und weitere Postings:
http://www.openldap.org/lists/openldap-devel/200802/msg00100.html
Und überhaupt veraltete Software einzusetzen, welche von den
eigentlichen Autoren nicht mehr unterstützt wird, ist keinesfalls
"stable". Ach ja...
Ciao, Michael.
Wolfgang Ewert
> Es betrifft nur Debian >= 4.0 Systeme, ...
und abgeleitete, wie Knoppix und Ubuntu z.B.
my 0.02€
Wolfgang
--
Nirgendwo hängt der Schulerfolg so stark von Einkommen und Vorbildung
der Eltern ab wie in D'land. Das dt. Schulsystem versagt bei der
Förderung von Arbeiter- und Migrantenkindern. (dpa/FTD 22.11.04)
Ralph Angenendt
> Und überhaupt veraltete Software einzusetzen, welche von den
> eigentlichen Autoren nicht mehr unterstützt wird, ist keinesfalls
> "stable".
I beg to differ.
Schau dir mal (z.B.) RHEL 2.1 oder auch nur RHEL 3 an - auch dort ist
Software enthalten, die vom upstream schon lange nicht mehr unterstützt
wird. Da sich Red Hat bei seinen Enterprisekunden aber keinerlei API-
und ABI-Breakage leisten kann - theoretisch zumindest - bleibt ihnen gar
nichts anderes übrig, als z.B. Securitypatches in die alten Versionen
rückzuportieren.
Das dass nicht immer funktioniert, kann man an aktuellen Samba-Paketen
für RHEL 4 sehen (und an upgedateten
Firefox/Thunderbird/OOffice-Paketen), aber normalerweise wird das so
durchgezogen.
Und das hat für mich (als Kunden) *viel* mit "stable" zu tun, wenn ich
mich 7 Jahre lang darauf verlassen kann, dass ich security-patches
bekomme, sich aber APIs und ABIs nicht ändern (und mir nicht plötzlich
neue Versionen mit einem völlig anderen Verhalten unter den Hintern
installiert werden).
Dafür muss man sich dann allerdings einen Stamm von Entwicklern leisten
können und wollen, die wissen, was sie machen.
Ralph
--
Von Bismarck stammt der Satz, dass die Leute ruhiger schlafen könnten, wenn
sie nicht wissen, wie Gesetze und Würste gemacht werden. Wer heute diesen Satz
zitiert, beleidigt Würste. -- Heribert Prantl zum geplanten BKA-Gesetz
Nicht schreiben können: http://lestighaniker.de/
Sebastian G.
> Stimmt etwas mit meinem Newsreader nicht oder ist das immer noch das
> Ringen um die richtigen Worte bzw. vollkommene Sprachlosigkeit, welche
> dieses nunmehr schon mehrere Tage währende (fast schon gespenstische)
> Schweigen hervorruft, angesichts des größten denkbaren Unfalles in der
> Geschichte der modernen Kryptographie?
Wie? Ist die denn das #ifdef DEV_RANDOM im Sourcecode nicht aufgefallen?
Uninitialisierter Speicher ist nur eine der vielen Entropie-Quellen, deren
sich OpenSSL bedient. Die Meldung besagt im Wesentlichen nur, dass, wenn du
*ausschliesslich* diese verwendet hast, du ein Problem hast - aber das haft
du auch ohne diesen Bug, weil viel zu leicht bruteforcebar.
Roman Racine
> - Was ist mit aufgezeichneten SSH-Sitzungen (welchen Einfluss hat der
> host key auf die Sitzungsschlüssel) Ist es FUD? Wenn nein, warum nicht?
> Was ist z.B. der Einfluss auf einen aufgezeichnete Diffie-Hellman-
> Schlüsseltausch? Beide varianten, Alice->Bob oder Bob->Alice (Alice hat
> Debian, Bob nicht)
Naja, das sind die eher theoretischen Angriffsszenarien. Wenn du einen der
beiden Private Keys hast bzw. leicht berechnen kannst, kannst du die
Verbindung natürlich entschlüsseln.
Das grosse Problem ist m.E., dass sämtliche möglichen Private-Keys, die auf
Debian Etch und abgeleiteten Systemen generiert werden können, nun bekannt
sind und garantiert schon Skripts im Umlauf sind, mit denen man sämtliche
möglichen Keys in ganzen IP-Ranges und gängigen Loginnamen (z.B. root ...)
durchprobieren kann. Deswegen dürften in nächster Zeit tausende von Servern
gehackt werden.
> - Was ist mit Tor-Hidden-Service-Keys? (Es gibt brute force tools für die
> Generierung von .onion adressen die im Ergebnis eine bestimmte RegExp
> matchen sollen, warum haben die in den letzten 2 Jahren *nicht* um
> Größenordnungen besser funktioniert als in der Theorie zu erwarten
> gewesen wäre, obwohl sie angeblich(?) auch schwach sind?) Ist es FUD?
> Wenn nein, warum nicht?
Grundsätzlich reicht es bei dieser mehrstufigen zwiebelartigen
Verschlüsselung, wenn zumindest ein Key unterwegs nicht kompromittiert ist.
Solange nicht die ganze Kette, über die die Daten laufen, kompromittierte
Keys einsetzt, ist die Verbindung noch als sicher zu betrachten.
> - Warum wird mancherorts geschrieben, auch gute Schlüssel, die in
> irgendwelchen SSH(?) SSL(?) Whatever(?) Verbindungen mit betroffenen
> Hosts zum Einsatz kamem seien ebenfals als kompromittiert zu betrachten?
> Warum? welche Mechanismen greifen hier?
Das gilt nur für DSA-Schlüssel. DSA-Signaturen sind auf zufällige Werte
angewiesen, s. http://de.wikipedia.org/wiki/Digital_Signature_Algorithm Ist
einem Angreifer der zufällige Wert bekannt, kann er daraus den Schlüssel
berechnen. Wenn der Random Number Generator nur 2^15 Werte annehmen kann,
kann man daraus den Schlüssel leicht berechnen.
> - Welche anderen, nicht so offensichtlichen Implikationen ergeben sich,
> und warum?
Aus meiner Sicht hauptsächlich die, dass auch Systeme betroffen sein können,
die diese Schwäche nie hatten, sobald irgendjemand einen schwachen Key
darauf kopiert hat. Für Debian & Co. stehen immerhin Tools zur Verfügung,
mit denen man schwache Keys leicht ausfindig machen kann, Hersteller
anderer Systeme lassen sich da möglicherweise mehr Zeit.
Gruss
Roman°
--
IRC: Freenode, #usenet-friends
Bernd Kreuss
>> - Was ist mit Tor-Hidden-Service-Keys? (Es gibt brute force tools für
>> die Generierung von .onion adressen die im Ergebnis eine bestimmte
>> RegExp matchen sollen, warum haben die in den letzten 2 Jahren *nicht*
>> um Größenordnungen besser funktioniert als in der Theorie zu erwarten
>> gewesen wäre, obwohl sie angeblich(?) auch schwach sind?) Ist es FUD?
>> Wenn nein, warum nicht?
>
> Grundsätzlich reicht es bei dieser mehrstufigen zwiebelartigen
> Verschlüsselung, wenn zumindest ein Key unterwegs nicht kompromittiert
> ist. Solange nicht die ganze Kette, über die die Daten laufen,
> kompromittierte Keys einsetzt, ist die Verbindung noch als sicher zu
> betrachten.
Das war ein Mißverständnis, ich meinte wirklich nur die hidden-service-
keys. Diese haben mit den eigentlichen Tunneln zwischen den nodes erstmal
nichts zu tun. Die Tunnel sind gewöhnliche ssl-Verbindungen und sind
(auch nachträglich) geknackt, wenn alle 3 Nodes schwache Schlüssel hatten.
Die hidden service keys sind Schlüsselpaare, die einen hidden-service
identifizieren und der Fingerprint ist gleichzeitig die .onion Adresse.
Das Ziel bei einem Angriff auf einen hidden service key ist es in den
Besitz eines Schlüsselpaares zu gelangen, das denselben Fingerprint hat
und man somit einen hidden service mit derselben .onion-Adresse wie das
Opfer betreiben kann.
Es gibt ein Tool, welches mittels brute force Tor solange neue Schlüssel
erzeugen läßt bis einer dabei ist, der einer vorgegebenen RegExp
entspricht, das kann man dazu verwenden, seine Initialien in
seiner .onion-Adresse zu verewigen, es dauert aber ewig, wenn mehr als
nur eine Handvoll Zeichen matchen sollen. Theorethisch hätte aber dieses
Tool auf einem Debian-Rechner ein völlig anderes Verhalten zeigen müssen,
wenn es stimmt was seitens Tor über diese Keys im Zusammenhang mit der
debian-Geschichte zu lesen ist. Trotzdem ist nirgendwo zu lesen, dass
bislang jemals auch nur eine einzige derartige Kollision herbeigeführt
wurde.
Das ist es, was mich hier ein bisschen stutzig macht, und eine mühsam
etablierte .onion-Adresse will man nicht einfach so auf Verdacht
wegwerfen.
Carsten Krueger
> - Was ist mit aufgezeichneten SSH-Sitzungen (welchen Einfluss hat der
> host key auf die Sitzungsschlüssel)
Das frag ich mich auch. Verwendet SSH "Perfect Forward Secrecy"?
Wenn ja, ist das auch durch zu wenig zu Fall gebrochen.
Wenn nein, wär es eine gute Idee das zu implementieren.
> - Warum wird mancherorts geschrieben, auch gute Schlüssel, die in
> irgendwelchen SSH(?) SSL(?) Whatever(?) Verbindungen mit betroffenen
> Hosts zum Einsatz kamem seien ebenfals als kompromittiert zu betrachten?
> Warum? welche Mechanismen greifen hier?
Die Schlüssel nicht, aber die Verbindungen evtl.
Bei Publickeyverfahren läuft ja niemals der Schlüssel über die Leitung.
Gruß Carsten
--
ID = 0x2BFBF5D8 FP = 53CA 1609 B00A D2DB A066 314C 6493 69AB 2BFB F5D8
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://www.spamgourmet.com/ + http://www.temporaryinbox.com/ - Antispam
cakruege (at) gmail (dot) com | http://www.geocities.com/mungfaq/
Thomas Hochstein
> Jeder dürfte mittlerweile mitbekommen haben, worum es geht. Wozu dann
> noch hier explizit erwähnen?
Weil - zumindest bei mir - eine ganze Menge Fragen offen geblieben
sind; Bernd ist mir insofern nur zuvorgekommen. Ich wundere mich auch
schon seit Tagen, daß hier nichts dazu zu lesen ist, hatte nur keine
Zeit, ein längeres Posting zu verfassen.
Klar sind mir Ursache/Hergang (1) und unmittelbare Folgen (2):
1. Der Debian-Maintainer hat sich nach einem Bugreport, der beim
Untersuchen (mittels valgrind) von gegen die libssl gelinkten Code
haufenweise auftretende Fehlermeldungen bemängelt, an die Maintainer
von OpenSSL gewandt und nachgefragt, ob es gravierende Folgen für den
Zufallszahlengenerator habe, wenn er den Code-Teil, der
uninitialisierten Speicher zum Entropie-Pool hinzufügt, entfernt. Das
wurde verneint. Er hat aber versehentlich nicht nur diesen Teil des
Codes, der im Source auch schon entsprechend gekennzeichnet war,
weggepatcht, sondern auch den Teil, der *überhaupt* den Entropie-Pool
füllt, so daß das einzig zufällige des Zufallszahlengenerators wohl
die PID war; das ist weder ihm noch den OpenSSL-Maintainer
aufgefallen, noch seitdem sonst jemand - ein klassisches
Kommunikationsversagen.
2. Das führt dazu, daß alle mit diesem OpenSSL erzeugten Schlüssel
(also mit allem neuer als Sarge seit dem entsprechenden Datum) zu
einem wahnsinnig kleinen Schlüsselraum gehören, der ratbar ist, und
daher ersetzt werden müssen.
(Wenn ich da etwas grob durcheinander geworfen, bin ich für eine
Richtigstellung dankbar.)
*Nicht* klar mangels ausreichender kryptographischer Kenntnisse sind
mir bisher die weiteren Implikationen, was andere Keys (3) und
potentiell aufgezeichneten Datenverkehr (4) betrifft:
3. Man liest, es seien auch DSA-/DSS-SSH-Keys kompromittierbar, wenn
sie einmal zur Authentifizierung in Zusammenhang mit einem "schwachen"
OpenSSL verwendet worden seien. Hier ist mir nicht klar, was das
bedeutet. Gilt das
- nur dann, wenn der SSH-Client, von dem aus zu einer anderen Maschine
connected wird, auf einem System mit "schwachen" OpenSSL läuft,
- oder auch dann, wenn der SSH-Server, also die Stelle, *zu* der
connected wird, mit "schwachen" OpenSSL läuft?
Inwiefern ist es dabei relevant, ob der Hostkey des Servers
kompromittierbar, da mit "schwachen" OpenSSL erzeugt, ist?
4. Wie sieht das mit früheren SSH- oder auch SSL-/TLS-Verbindungen
aus, wenn
- der SSH-Key, mit dem paßwortlos authentifiziert wurde,
kompromittierbar war,
- der SSH-Hostkey kompromittierbar war, oder wenn
- das SSL-Zertifikat des Mail- oder Webservers kompromittierbar war?
Lassen sich dann die übertragenen Inhaltsdaten nachträglich
entschlüsseln, falls der Datenverkehr aufgezeichnet wurde? Das wäre ja
relevant nicht für den Bereich SSH, sondern auch für bspw.
HTTPS-Verbindungen, bei denen Paßworte, Kreditkartendaten,
personenbezogene Daten usw. transfertiert wurden.
Kann jemand dazu - und vielleicht auch zu weiteren Seiteneffekten, die
mir noch gar nicht eingefallen sind - etwas möglichst fundiertes
beitragen? ;)
Man liest viel Spekulation und worst-case-Szenarien, aber wenig
definitives - oder ich habe es bisher nicht gefunden.
Danke & Gruß,
-thh
Ralph Angenendt
> Wie? Ist die denn das #ifdef DEV_RANDOM im Sourcecode nicht aufgefallen?
> Uninitialisierter Speicher ist nur eine der vielen Entropie-Quellen, deren
> sich OpenSSL bedient. Die Meldung besagt im Wesentlichen nur, dass, wenn du
> *ausschliesslich* diese verwendet hast, du ein Problem hast
Äh, ne. Nochmal den Bugreport lesen, bitte. Und eventuell Beiträge
drumherum. So wie es aussieht wurde nur die PID als Entropiequelle
genutzt.
Thomas Hochstein
> Uninitialisierter Speicher ist nur eine der vielen Entropie-Quellen, deren
> sich OpenSSL bedient. Die Meldung besagt im Wesentlichen nur, dass, wenn du
> *ausschliesslich* diese verwendet hast, du ein Problem hast - aber das haft
> du auch ohne diesen Bug, weil viel zu leicht bruteforcebar.
Nein, die "Meldung", die gemeint ist, bezieht sich darauf, daß in der
Debian-Version nicht nur das Hinzufügen von Entropie durch
uninitialisierten Speicher weggepatcht wurde, sondern - versehentlich
- auch das Hinzufügen von Entropie *überhaupt*, so daß der einzige
"Zufalls"anteil, der übriggeblieben ist, die PID war. Das ist ...
etwas wenig.
-thh
Roman Racine
> Arno Welzel schrieb:
>
>> Jeder dürfte mittlerweile mitbekommen haben, worum es geht. Wozu dann
>> noch hier explizit erwähnen?
>
> Weil - zumindest bei mir - eine ganze Menge Fragen offen geblieben
> sind; Bernd ist mir insofern nur zuvorgekommen. Ich wundere mich auch
> schon seit Tagen, daß hier nichts dazu zu lesen ist, hatte nur keine
> Zeit, ein längeres Posting zu verfassen.
>
> Klar sind mir Ursache/Hergang (1) und unmittelbare Folgen (2):
>
> 1. Der Debian-Maintainer hat sich nach einem Bugreport, der beim
> Untersuchen (mittels valgrind) von gegen die libssl gelinkten Code
> haufenweise auftretende Fehlermeldungen bemängelt, an die Maintainer
> von OpenSSL gewandt und nachgefragt, ob es gravierende Folgen für den
> Zufallszahlengenerator habe, wenn er den Code-Teil, der
> uninitialisierten Speicher zum Entropie-Pool hinzufügt, entfernt. Das
> wurde verneint. Er hat aber versehentlich nicht nur diesen Teil des
> Codes, der im Source auch schon entsprechend gekennzeichnet war,
> weggepatcht, sondern auch den Teil, der *überhaupt* den Entropie-Pool
> füllt, so daß das einzig zufällige des Zufallszahlengenerators wohl
> die PID war; das ist weder ihm noch den OpenSSL-Maintainer
> aufgefallen, noch seitdem sonst jemand - ein klassisches
> Kommunikationsversagen.
Der versehentlich auskommentierte Code befindet ist 200 Zeilen entfernt und
befindet sich nicht einmal mehr in der gleichen Funktion ... Es ist IMHO
schon sehr bedenklich, dass dieser Fehler in einem derart wichtigen Paket
niemandem aufgefallen ist.
> 3. Man liest, es seien auch DSA-/DSS-SSH-Keys kompromittierbar, wenn
> sie einmal zur Authentifizierung in Zusammenhang mit einem "schwachen"
> OpenSSL verwendet worden seien. Hier ist mir nicht klar, was das
> bedeutet.
Schau dir http://de.wikipedia.org/wiki/Digital_Signature_Algorithm an. Wenn
du die Nachricht m mit der Signatur (s1,s2) abfängst und dir q bekannt ist,
kannst du, sofern dir s bekannt ist, leicht den Private-Key berechnen,
indem du
(s * s2 - SHA1(m)) * s1^-1 = x berechnest.
Sofern s nicht zufällig aus einer genügend grossen Wertemenge gewählt wird
(2^15 zählt nicht dazu), kann x berechnet werden. Sobald der DSS-Schlüssel
*einmal* mit einem schlechten Zufallszahlengenerator zum Signieren
eingesetzt wird, ist er also potentiell gebrochen. Das System des
Empfängers spielt dagegen keine Rolle, ja, es darf gar keine Rolle spielen,
die Sicherheit einer Signatur darf ja nicht vom Empfänger abhängig sein.
Sebastian G.
> Aeh. Ich glaube Du hast das missverstanden...
Nein, ich glaube nur, dass wohl so ziemlich alle anderen das missverstanden
haben. Ich habe mir naemlich den Quellcode angeschaut.
Roman Racine
>>> Wie? Ist die denn das #ifdef DEV_RANDOM im Sourcecode nicht aufgefallen?
>>> Uninitialisierter Speicher ist nur eine der vielen Entropie-Quellen,
>>> deren sich OpenSSL bedient. Die Meldung besagt im Wesentlichen nur,
>>> dass, wenn du *ausschliesslich* diese verwendet hast, du ein Problem
>>> hast - aber das haft du auch ohne diesen Bug, weil viel zu leicht
>>> bruteforcebar.
>>
>> Aeh. Ich glaube Du hast das missverstanden...
>
>
> Nein, ich glaube nur, dass wohl so ziemlich alle anderen das
> missverstanden haben. Ich habe mir naemlich den Quellcode angeschaut.
Wie erklärst du dir denn die Tatsache, dass eine Liste der Fingerprints
sämtlicher je mit Debian-Etch erzeugten Keys gerade mal ein paar Megabyte
gross ist?
Sebastian G.
> Klar sind mir Ursache/Hergang (1) und unmittelbare Folgen (2):
>
> 1. Der Debian-Maintainer hat sich nach einem Bugreport, der beim
> Untersuchen (mittels valgrind) von gegen die libssl gelinkten Code
> haufenweise auftretende Fehlermeldungen bemängelt, an die Maintainer
> von OpenSSL gewandt und nachgefragt, ob es gravierende Folgen für den
> Zufallszahlengenerator habe, wenn er den Code-Teil, der
> uninitialisierten Speicher zum Entropie-Pool hinzufügt, entfernt. Das
> wurde verneint.
Meinen Quellen zufolge hat er ueberhaupt nicht nachgefragt, sondern die
Aenderung einfach blind appliziert. Drum ist auch nur die bei Debian
gepatchte Variante von OpenSSL verwundbar, nicht aber das Original.
> Er hat aber versehentlich nicht nur diesen Teil des
> Codes, der im Source auch schon entsprechend gekennzeichnet war,
> weggepatcht, sondern auch den Teil, der *überhaupt* den Entropie-Pool
> füllt,
Da sieht im Quellcode aber ganz anders aus. Dort ist es nur ein memset() auf
dem Speicherbereich. Herrje, in der naechsten Zeile steht dann doch schon
unmittelbar "#ifdef DEV_RANDOM" und anschliessend der Code, welcher Entropie
aus /dev/random holt. Dann alle anderen Zufallsquellen. Und in diesem
Bereich wurde absolut nichts geaendert.
Auch ist es nicht plausibel bzgl. der Funktionsweise von Valgrind.
Sebastian G.
> · Well, Sebastian G. <se...@seppig.de> wrote:
>> Wie? Ist die denn das #ifdef DEV_RANDOM im Sourcecode nicht aufgefallen?
>> Uninitialisierter Speicher ist nur eine der vielen Entropie-Quellen, deren
>> sich OpenSSL bedient. Die Meldung besagt im Wesentlichen nur, dass, wenn du
>> *ausschliesslich* diese verwendet hast, du ein Problem hast
>
> Äh, ne. Nochmal den Bugreport lesen, bitte. Und eventuell Beiträge
> drumherum.
Hab ich. Und es deckt sich absolut nicht mit dem Quellcode, dessen Lesung
ich dir empfehlen wuerde.
> So wie es aussieht wurde nur die PID als Entropiequelle
> genutzt.
So wie es aussieht folgt direkt nach dem fraglichen Aufruf von memset()
unmittelbar ein "#ifdef RANDOM_DEVICE" und der Code, welcher an den (nun
ausgenullten Puffer) weitere Entropie anhaengt.
Sebastian G.
Das ist... etwas falsch.
Sebastian G.
Gar nicht, kann ich naemlich im Gegentest nicht nachvollziehen.
Thomas Hochstein
> Meinen Quellen zufolge hat er ueberhaupt nicht nachgefragt, sondern die
> Aenderung einfach blind appliziert. Drum ist auch nur die bei Debian
> gepatchte Variante von OpenSSL verwundbar, nicht aber das Original.
<http://marc.info/?t=114651088900003&r=1&w=2>
> Da sieht im Quellcode aber ganz anders aus. Dort ist es nur ein memset() auf
> dem Speicherbereich. Herrje, in der naechsten Zeile steht dann doch schon
> unmittelbar "#ifdef DEV_RANDOM"
Diese Zeichenfolge kommt im Quelltext von md_rand.c gar nicht vor,
AFAIS.
-thh
Thomas Hochstein
> Sobald der DSS-Schlüssel
> *einmal* mit einem schlechten Zufallszahlengenerator zum Signieren
> eingesetzt wird, ist er also potentiell gebrochen.
Und das - Signieren - kommt an welcher Stelle vor? Soweit ich das
SSH-Protokoll verstanden habe, erfolgt die Authentifizierung per Key
in der Weise, daß der Server eine Challenge sendet, die er mit dem in
der authorized_keys hinterlegten Pubkey des Clients verschlüsselt. Der
Client entschlüsselt die Challenge und sendet sie zurück, ist damit
authentifiziert. Wo kommt da eine Signatur ins Spiel? Und: die
Challenge, also die Zufallszahl, wird dabei doch auf dem *Server*
erzeugt?
> Das System des
> Empfängers spielt dagegen keine Rolle, ja, es darf gar keine Rolle spielen,
> die Sicherheit einer Signatur darf ja nicht vom Empfänger abhängig sein.
Ich habe den Eindruck, ich habe da noch etwas wesentliches nicht
verstanden.
-thh
Bernd Kreuss
> Sobald der
> DSS-Schlüssel *einmal* mit einem schlechten Zufallszahlengenerator zum
> Signieren eingesetzt wird, ist er also potentiell gebrochen.
Das bedeutet also im Klartext, auch viel ältere ehemals gute Schlüssel
wurden alleine dadurch, dass sie auf einem kaputten System zum Signieren
eingesetzt wurden kompromittiert.
Bei welchen Operationen wird überall sgniert?
- alte (gute) S/MIME-Zerifikate gehen allein durch das Verwenden mit der
kaputten libssl kaputt, jemand muss nur eine signierte Mail aus der
letzten Zeit rauskramen und bricht den Schlüssel, kann man das so stehen
lassen, oder ist das wieder ne andere Baustelle?
- ich hab ein altes (gutes) Schlüsselpaar aus alten Zeiten für SSH public-
key-auth auf meinem Laptop mit fehlerhaftem Ubuntu verwendet, um mich auf
verschiedenen Servern für SSH zu authentifizieren, wird hierbei während
des Handshakes etwas mit meinem Schlüssel signiert? Falls ja, wird das ja
hinterher vom Server gleich wieder weggeworfen. Aber: wenn jemand den
betreffenden Trafic vorratsgespeichert hat:
* kann er damit direkt etwas anfangen (ist die Authentifizierung
unverschlüsselt)?
* oder muss er dazu erst einen SSH-Sitzungsschlüssel brechen,
um eine Signatur von mir zu sehen? Und wäre das in diesem
Falle möglich (das nachträgliche Brechen von SSH)?
Richard W. Könning
>Thomas Hochstein wrote:
>
>
>> Klar sind mir Ursache/Hergang (1) und unmittelbare Folgen (2):
>>
>> 1. Der Debian-Maintainer hat sich nach einem Bugreport, der beim
>> Untersuchen (mittels valgrind) von gegen die libssl gelinkten Code
>> haufenweise auftretende Fehlermeldungen bemängelt, an die Maintainer
>> von OpenSSL gewandt und nachgefragt, ob es gravierende Folgen für den
>> Zufallszahlengenerator habe, wenn er den Code-Teil, der
>> uninitialisierten Speicher zum Entropie-Pool hinzufügt, entfernt. Das
>> wurde verneint.
>
>
>Meinen Quellen zufolge hat er ueberhaupt nicht nachgefragt, sondern die
Und was sind Deine Quellen? Ich habe jedenfalls seine Nachfrage immer
noch in einer Mailbox@work stehen.
>Aenderung einfach blind appliziert. Drum ist auch nur die bei Debian
>gepatchte Variante von OpenSSL verwundbar, nicht aber das Original.
>
>> Er hat aber versehentlich nicht nur diesen Teil des
>> Codes, der im Source auch schon entsprechend gekennzeichnet war,
>> weggepatcht, sondern auch den Teil, der *überhaupt* den Entropie-Pool
>> füllt,
>
>
>Da sieht im Quellcode aber ganz anders aus. Dort ist es nur ein memset() auf
>dem Speicherbereich. Herrje, in der naechsten Zeile steht dann doch schon
>unmittelbar "#ifdef DEV_RANDOM" und anschliessend der Code, welcher Entropie
>aus /dev/random holt. Dann alle anderen Zufallsquellen. Und in diesem
>Bereich wurde absolut nichts geaendert.
Wovon redest Du? Jedenfalls von etwas anderem, als die restlichen
Threadteilnehmer.
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Bernd Kreuss
> Thomas Hochstein wrote:
>> Nein, die "Meldung", die gemeint ist, bezieht sich darauf, daß in der
>> Debian-Version nicht nur das Hinzufügen von Entropie durch
>> uninitialisierten Speicher weggepatcht wurde, sondern - versehentlich -
>> auch das Hinzufügen von Entropie *überhaupt*, so daß der einzige
>> "Zufalls"anteil, der übriggeblieben ist, die PID war. Das ist ... etwas
>> wenig.
>
>
> Das ist... etwas falsch.
Nein, das ist vollkommen korrekt.
Hier kannst Du es aus erster Hand nachlesen:
http://www.links.org/?p=328
"[...]
And this leads me to the second point. Many people seem to be confused
about what change was actually made. There were, in fact, two changes.
The first concerned a function called ssleay_rand_add(). As a developer
using OpenSSL you would never call this function directly, but it is
usually (unless a custom PRNG has been substituted, as happens in FIPS
mode, for example) called indirectly via RAND_add(). This call is the
only way entropy can be added to the PRNG’s pool. OpenSSL calls RAND_add
() on buffers that may not have been initialised in a couple of places,
and this is the cause of the valgrind warnings. However, rather than fix
the calls to RAND_add(), the Debian maintainer instead removed the code
that added the buffer handed to ssleay_rand_add() to the pool. This meant
that the pool ended up with essentially no entropy. Clearly this was a
very bad idea.
The second change was in ssleay_rand_bytes(), a function that extracts
randomness from the pool into a buffer. Again, applications would access
this via RAND_bytes() rather than directly. In this function, the
contents of the buffer before it is filled are added to the pool. Once
more, this could be uninitialised. The Debian developer also removed this
call, and that is fine.
[...]"
Das hate zur Folge, dass der mögliche Schlüsselraum 2 Jahre lang nur noch
15 (in Worten FÜNFZEHN!) Bit umfasste.
Hier nochmal der fatale Patch vor 2 Jahren:
http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&r1=140&r2=141
Und hier der Fix von vom 7. Mai
http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?r1=300&r2=299
Richard W. Könning
>Arno Welzel schrieb:
>
>> Jeder dürfte mittlerweile mitbekommen haben, worum es geht. Wozu dann
>> noch hier explizit erwähnen?
>
>Weil - zumindest bei mir - eine ganze Menge Fragen offen geblieben
>sind; Bernd ist mir insofern nur zuvorgekommen. Ich wundere mich auch
>schon seit Tagen, daß hier nichts dazu zu lesen ist, hatte nur keine
>Zeit, ein längeres Posting zu verfassen.
>
>Klar sind mir Ursache/Hergang (1) und unmittelbare Folgen (2):
>
>1. Der Debian-Maintainer hat sich nach einem Bugreport, der beim
>Untersuchen (mittels valgrind) von gegen die libssl gelinkten Code
>haufenweise auftretende Fehlermeldungen bemängelt, an die Maintainer
>von OpenSSL gewandt und nachgefragt, ob es gravierende Folgen für den
>Zufallszahlengenerator habe, wenn er den Code-Teil, der
>uninitialisierten Speicher zum Entropie-Pool hinzufügt, entfernt. Das
>wurde verneint. Er hat aber versehentlich nicht nur diesen Teil des
>Codes, der im Source auch schon entsprechend gekennzeichnet war,
>weggepatcht, sondern auch den Teil, der *überhaupt* den Entropie-Pool
>füllt, so daß das einzig zufällige des Zufallszahlengenerators wohl
>die PID war; das ist weder ihm noch den OpenSSL-Maintainer
>aufgefallen, noch seitdem sonst jemand - ein klassisches
>Kommunikationsversagen.
Das ist für meinen Geschmack etwas zu kurz gesprungen. Das Problem am
Anfang war imho Toolgläubigkeit verbunden mit mangelnder
Toolbeherrschung. Man brauchte keine speziellen OpenSSL-Kenntnisse, um
zu erkennen, daß es an der kritischen Stelle um einen reinrassigen
*Input*-Parameter ging (im Gegensatz zu der anderen Stelle, wo ein
*Output*-Parameter nebenbei als i.a. nicht initialisierter
Input-Parameter "mißbraucht" wurde). Wenn valgrind aber den Zugriff
auf einen mit nicht-definierten Daten versorgten Input-Parameter
anmeckert, dann kann man in aller Regel davon ausgehen, daß irgendwas
mit dem *Aufruf* der Funktion nicht ganz stimmt, nicht mit dem Zugriff
*innerhalb* der Funktion (man läßt sich ja auch nicht am Magen
operieren, nur weil man sich ab und an mit verdorbenem Essen den Magen
verdirbt). Wenn, dann hätte man an den Stellen ansetzen müssen, wo der
Aufruf (in diesem Fall durchaus beabsichtigt) mit uninitialisierten
Datenfeldern erfolgte.
In der einen Antwort auf der Mailing-Liste hat der gute Kurt dann ja
von Geoff Thorpe den Rat bekommen, -DPURIFY zu verwenden. Wenn er
nachgefragt hätte, warum an der anderen Stelle nicht ebenfalls ein
#ifndef PURIFY steht, hätte sich sein Fehler aufgeklärt. Stattdessen
hat er diesen Rat ignoriert und nur die andere Antwort von Ulf Möller
verwendet, die etwas unglücklich war, weil der Fragesteller nicht
realisiert hat, daß er faktisch nur eine (korrekte) Antwort auf einen
Teil seiner Fragen bekommen hat. Daß er nur Zeilennummern, nicht aber
die Namen der Funktionen angegeben hat, war auch nicht sonderlich
geschickt (die Erwähnung von ssleay_rand_add hätte vielleicht doch
jemanden darauf gebracht, im Code nachzuschauen).
>2. Das führt dazu, daß alle mit diesem OpenSSL erzeugten Schlüssel
>(also mit allem neuer als Sarge seit dem entsprechenden Datum) zu
>einem wahnsinnig kleinen Schlüsselraum gehören, der ratbar ist, und
>daher ersetzt werden müssen.
>
>(Wenn ich da etwas grob durcheinander geworfen, bin ich für eine
>Richtigstellung dankbar.)
>
>*Nicht* klar mangels ausreichender kryptographischer Kenntnisse sind
>mir bisher die weiteren Implikationen, was andere Keys (3) und
>potentiell aufgezeichneten Datenverkehr (4) betrifft:
>
>3. Man liest, es seien auch DSA-/DSS-SSH-Keys kompromittierbar, wenn
>sie einmal zur Authentifizierung in Zusammenhang mit einem "schwachen"
>OpenSSL verwendet worden seien. Hier ist mir nicht klar, was das
>bedeutet. Gilt das
>- nur dann, wenn der SSH-Client, von dem aus zu einer anderen Maschine
>connected wird, auf einem System mit "schwachen" OpenSSL läuft,
>- oder auch dann, wenn der SSH-Server, also die Stelle, *zu* der
>connected wird, mit "schwachen" OpenSSL läuft?
DSA/DSS kenne ich zu wenig, als daß ich mir eine qualifizierte Antwort
zutraue.
>Inwiefern ist es dabei relevant, ob der Hostkey des Servers
>kompromittierbar, da mit "schwachen" OpenSSL erzeugt, ist?
>
>4. Wie sieht das mit früheren SSH- oder auch SSL-/TLS-Verbindungen
>aus, wenn
>- der SSH-Key, mit dem paßwortlos authentifiziert wurde,
>kompromittierbar war,
>- der SSH-Hostkey kompromittierbar war, oder wenn
>- das SSL-Zertifikat des Mail- oder Webservers kompromittierbar war?
>
>Lassen sich dann die übertragenen Inhaltsdaten nachträglich
>entschlüsseln, falls der Datenverkehr aufgezeichnet wurde? Das wäre ja
Bei Schlüsseln, die nur für Authentifizierung verwendet werden,
bewirkt eine Kompromittierung nur, daß ein MITM-Angriff zum Zeitpunkt
des Datentransfers möglich gewesen wäre. Hier muß man die
Wahrscheinlichkeit abschätzen, daß das Debian-Problem schon länger in
den einschlägigen Kreisen bekannt und gegen einen selbst ausgenutzt
worden ist, eine nachträgliche Ausnutzung ist nicht möglich.
>relevant nicht für den Bereich SSH, sondern auch für bspw.
>HTTPS-Verbindungen, bei denen Paßworte, Kreditkartendaten,
>personenbezogene Daten usw. transfertiert wurden.
Bei Schlüsseln, die für die Verschlüsselung verwendet wurden, ist es
komplizierter. Bei SSL käme es darauf an, welche Cipher-Suite genau
verwendet worden ist. Wenn ein betroffener RSA-Schlüssel auch für die
Verschlüsselung verwendet wurde, dann kann eine aufgezeichnete
Verbindung vergleichsweise einfach entschlüsselbar sein. Wurde
hingegen eine Cipher-Suite mit "Perfect Forward Secrecy" (also z.B.
aus der EDH-Klasse) verwendet, dann kommt es darauf an, ob auch ein
Angriff auf den kurzlebigen (ephemeral) Schlüssel möglich ist.
Ausgeschlossen ist ein solcher Angriff nicht, er dürfte aber in vielen
Fällen schwieriger sein, da zum einen der OpenSSL-PRNG schon eine
längere, unbekannte Zugriffshistorie haben kann (die zumindestens ein
paar Bit zusätzliche Sicherheit bieten kann), zum anderen hat man
(zumindestens bei EDH) evtl. etwas bessere Karten, wenn zumindestens
auf einer Seite ein nicht verwundbarer PRNG involviert ist. Ob das
ausreicht, hängt von vielen Wenn und Abers und der jeweils konkreten
Situation ab, da wird man keine allgemeingültige Antwort geben können.
Im Grunde gibt es da nur das Prinzip Hoffnung.
>Kann jemand dazu - und vielleicht auch zu weiteren Seiteneffekten, die
>mir noch gar nicht eingefallen sind - etwas möglichst fundiertes
>beitragen? ;)
>
>Man liest viel Spekulation und worst-case-Szenarien, aber wenig
>definitives - oder ich habe es bisher nicht gefunden.
Worst-Case-Szenarien kann man noch vergleichsweise einfach abschätzen,
da man dort z.B. von einem frisch gestarteten OpenSSL-PRNG ausgeht.
Die reale Situation kann etwas besser aussehen, muß es aber nicht,
c'est la vie.
Richard W. Könning
>Mein Vertrauen in Software ohne finanziellen Hintergrund ist nun mehr endgueltig
>erschoepft. Sun&Co haben sehr wohl ihre Berechtigung.
Dort hätte genau der gleiche "Unfall" passieren können.
Bodo Moeller
>>> Wie? Ist die denn das #ifdef DEV_RANDOM im Sourcecode nicht aufgefallen?
>>> Uninitialisierter Speicher ist nur eine der vielen Entropie-Quellen, deren
>>> sich OpenSSL bedient.
>> Aeh. Ich glaube Du hast das missverstanden...
> Nein, ich glaube nur, dass wohl so ziemlich alle anderen das missverstanden
> haben. Ich habe mir naemlich den Quellcode angeschaut.
Aber offenbar das falsche File.
/dev/urandom usw. sind zwar in rand_unix.c als wichtige Zufallsquelle
vorgesehen; aber durch die kritische Änderung an md_rand.c
(http://xkcd.org/424/) im Debian-spezifischen Patch bleibt der Zustand
des Zufallszahlengenerators von den dort entnommenen Bytes unabhängig.
Damit ist in typischen Fällen die einzige Entropiequelle die PID,
der eigentlich nie die Aufgabe zugedacht war, zur Unvorhersehbarkeit
beizutragen.
Richard W. Könning
Ich habe den Eindruck, daß Du
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516 nur bis zum
ersten Eintrag gelesen hast und deshalb von etwas redest, was nicht
Grundlage dieses Threads ist. Um es nochmal deutlich zu sagen: es geht
um crypto/rand/md_rand.c, nicht um crypto/rand/rand_unix.c, Du kannst
so lange wie Du willst in rand_unix.c reinschauen, den Fehler in
md_rand.c wirst Du dort nicht entdecken. Btw, ist seppig2002 Deine
Heise-Forum-Inkarnation?
Richard W. Könning
Du bist *VÖLLIG* ahnungslos! Lern endlich, mehr als Überschriften und
Dokumentenanfänge zu lesen. Es geht um die Funktion
static void ssleay_rand_add(const void *buf, int num, double add),
der der gute Kurt den Parameter buf herausoperiert hat (hätte er das
durch seine "Korrektur" überflüssige Hochzählen von buf auch
auskommentiert, dann hätte er eine Compiler-Warnung bekommen, daß buf
nicht referenziert wird, aber so konsequent war er leider nicht).
Richard W. Könning
Jens Hektor
> Er hat aber versehentlich nicht nur diesen Teil des
> Codes, der im Source auch schon entsprechend gekennzeichnet war,
> weggepatcht, sondern auch den Teil, der *überhaupt* den Entropie-Pool
> füllt, so daß das einzig zufällige des Zufallszahlengenerators wohl
> die PID war; das ist weder ihm noch den OpenSSL-Maintainer
> aufgefallen, noch seitdem sonst jemand - ein klassisches
> Kommunikationsversagen.
Vor allem wirft es Fragen nach der Qualitätssicherung auf.
Diese sind sicher nicht Debian-spezifisch, aber diese gerade
bei den Geeks beliebte Distribution erleidet einen riesigen
Imageschaden. Dieses Ereignis darf man ruhig als GAU bezeichnen.
Ansonsten muss ich bemerken, dass ich als Nicht-Crypto-Experte
aber als Physiker vor dem Begriff Entropie offensichtlich
mehr Respekt habe, als der Durchschnittsinformatiker :-/
Sebastian G.
Ja, ich hab's gerade gesehen. Irgendwie haben saemtliche Artikel, die ich
gelesen habe, sich auf rand_unix.c und nicht md_rand.com bezogen, und eher
folgendes diskutiert:
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516>. Dort wird
naemlich nur genau der uninitialisierte Speicher geloescht.
Sebastian G.
>> Da sieht im Quellcode aber ganz anders aus. Dort ist es nur ein memset() auf
>> dem Speicherbereich. Herrje, in der naechsten Zeile steht dann doch schon
>> unmittelbar "#ifdef DEV_RANDOM" und anschliessend der Code, welcher Entropie
>> aus /dev/random holt. Dann alle anderen Zufallsquellen. Und in diesem
>> Bereich wurde absolut nichts geaendert.
>
> Wovon redest Du? Jedenfalls von etwas anderem, als die restlichen
> Threadteilnehmer.
Ja, ganz offenbar. Ich rede von
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516>, was scheinbar
genau die gleiche Geschichte, aber an einer anderen Stelle im Code ist.
Sebastian G.
> Hier nochmal der fatale Patch vor 2 Jahren:
> http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&r1=140&r2=141
>
> Und hier der Fix von vom 7. Mai
> http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?r1=300&r2=299
Entschuldige bitte, aber ich dachte (und wurde so informiert), dass es um
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516> geht. Gleiches
Problem, andere Stelle, weitaus weniger schlimm.
Sebastian G.
>> Nein, ich glaube nur, dass wohl so ziemlich alle anderen das missverstanden
>> haben. Ich habe mir naemlich den Quellcode angeschaut.
>
> Aber offenbar das falsche File.
Jupp, scheint so.
> /dev/urandom usw. sind zwar in rand_unix.c als wichtige Zufallsquelle
> vorgesehen; aber durch die kritische Änderung an md_rand.c
Meine Quellen haben auf
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516> verwiesen, das ist
rand_unix.c.
Juergen P. Meier
> Wolfgang Ewert <w.ewe...@gmx.de> wrote:
>> Hallo Juergen P. Meier, Du teiltest mit:
>>
>>> Es betrifft nur Debian >= 4.0 Systeme, ...
>>
>> und abgeleitete, wie Knoppix und Ubuntu z.B.
>>
>> my 0.02€
>
> Ja, aber wer nutzt schon Ubuntu, ausser ein paar geeks.
> SCNR,
> Chris
So ein Pseudoanynomer wie du wohl eher nicht.
fup2
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Juergen P. Meier
> · Well, Sebastian G. <se...@seppig.de> wrote:
>> Wie? Ist die denn das #ifdef DEV_RANDOM im Sourcecode nicht aufgefallen?
>> sich OpenSSL bedient. Die Meldung besagt im Wesentlichen nur, dass, wenn du
>> *ausschliesslich* diese verwendet hast, du ein Problem hast
>
> genutzt.
*sigh*. Die PID kam als einziges wirklich zum Zuge als Entropiequelle.
Juergen P. Meier
Juergen P. Meier
> Roman Racine schrieb:
>
>> Sobald der DSS-Schlüssel
>> *einmal* mit einem schlechten Zufallszahlengenerator zum Signieren
>> eingesetzt wird, ist er also potentiell gebrochen.
>
> Und das - Signieren - kommt an welcher Stelle vor? Soweit ich das
> SSH-Protokoll verstanden habe, erfolgt die Authentifizierung per Key
Der Session-Key fuer die symmetrische Verschluesselung der Datenpakete
(AES/3DES) wird verschluesselt und signiert -> Peng.
Das ist bei SSH nicht grundlegend anders als bei SSL/TLS, nur die
Protokolldetails sind verschieden.
HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
Juergen P. Meier
> Am Sat, 17 May 2008 00:35:24 +0200 schrieb Roman Racine:
>
>> Sobald der
>> DSS-Schlüssel *einmal* mit einem schlechten Zufallszahlengenerator zum
>> Signieren eingesetzt wird, ist er also potentiell gebrochen.
>
> Das bedeutet also im Klartext, auch viel ältere ehemals gute Schlüssel
> wurden alleine dadurch, dass sie auf einem kaputten System zum Signieren
> eingesetzt wurden kompromittiert.
AFAIU Nein. Komproimittiert wird lediglich die jeweils verschluesselte
Nachricht, micht der assymetrische Schluessel.
Den Schluessel kannst du auch mit dem Fehler nicht rekonstruieren.
Mit dem Fehler *erzeugte* Schluessel haben jedoch nur eine Entropie
(effektive Laenge) von 15 Bit (statt 2048 oder 4096) und sind damit
trivial vollstaendig enumerierbar (brute-force).
Juergen P. Meier
> Thomas Hochstein <t...@inter.net>:
>> Roman Racine schrieb:
>>
>>> Sobald der DSS-Schlüssel
>>> *einmal* mit einem schlechten Zufallszahlengenerator zum Signieren
>>> eingesetzt wird, ist er also potentiell gebrochen.
>>
>> Und das - Signieren - kommt an welcher Stelle vor? Soweit ich das
>> SSH-Protokoll verstanden habe, erfolgt die Authentifizierung per Key
>
> Der Session-Key fuer die symmetrische Verschluesselung der Datenpakete
> (AES/3DES) wird verschluesselt und signiert -> Peng.
Damit es nicht zu noch mehr Misverstaendnissen kommt:
Der Angriff auf SSH sieht dann z.B. so aus:
E. Vile schneidet° den SSH Handshake mit. D.h. er hat das mit dem
schlechten DSA-Schluessel verschluesselte Session-key (z.B. AES)
Paket. Auf dieses wendet er jetzt alle 2^15 Keyvarianten an, die er
vorberechnet hat.
Bei Erfolg hat er genau den verwendeten DSA-Schluessel des Opfers
geknackt.
Darum