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 muss jetzt jeder Debian/Ubuntu/Knopppix-Benutzer u.a. neue
SSH Keys erstellen, wenn diese nicht aelter als 2 Jahre sind.
° oder er bringt das Opfer dazu, einmal ssh evil-server einzutippen.
Thomas Hochstein
> Entschuldige bitte, aber ich dachte (und wurde so informiert), dass es um
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516> geht.
Korrekt.
> [...] andere Stelle, weitaus weniger schlimm.
Nein. Du hast allerdings offenbar nur den Bugreport gelesen, nicht den
daraufhin vorgeschlagenen (und dann implementierten) Fix.
-thh
Thomas Hochstein
> Meine Quellen haben auf
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516> verwiesen, das ist
> rand_unix.c.
Nur oberflächlich. Von dort zitiert:
| This is not the proper way to fix it. You can still find other
| cases where you'll get the same results.
|
| The problems are the following 2 pieces of code in
| crypto/rand/md_rand.c:
|
| 247:
| MD_Update(&m,buf,j);
|
| 467:
| #ifndef PURIFY
| MD_Update(&m,buf,j); /* purify complains */
| #endif
Das ist das Problem - genau genommen ist die Zeile 247 das Problem.
Die Zeile 467 ist der Codeteil, der valgrind und purify zum Meckern
brachte, den man weitgehend unschädlich entfernen kann und der auch in
den Debian-Paketen weiter herausgepatcht wird. Die Zeile 247 sieht
genauso aus, steht aber ganz woanders und tut auch etwas ganz anderes,
sie fügt nämlich überhaupt Entropie welcher Quelle auch immer dem Pool
hinzu. Sie ist versehentlich - ich nehme an, wegen der Codegleichheit
- auch weggepatcht worden.
-thh
--
/°\ --- JOIN NOW!!! ---
\ / ASCII ribbon campaign
X against HTML
/ \ in mail and news
Thomas Hochstein
> - 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:
Für diesen Fall (SSH-Client mit schwachem SSL) liest man zumindest
überall, daß dann ein "guter" DSA-Schlüssel kompromittierbar sei.
> * 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)?
Genau das ist die Frage, die ich bisher noch nirgendwo beantwortet
gesehen habe. Es liegt aber m.E. - für einen Laien ;) - jedenfalls
nicht fern, daß auch der Diffie-Hellman-Schlüsselaustausch gefährdet
ist, wenn eine der beiden beteiligten Parteien keine echten
Zufallszahlen erzeugen kann.
-thh
Thomas Hochstein
> Der Session-Key fuer die symmetrische Verschluesselung der Datenpakete
> (AES/3DES) wird verschluesselt und signiert -> Peng.
Mit dem Schlüssel, der auch für den SSH-Key-Auth verwendet wird? :-O
Und mit was wird verschlüsselt und signiert, wenn password based
authentification verwendet wird? *kopfkratz*
-thh
Thomas Hochstein
> 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).
Ich halte es auch für nicht völlig auszuschließen, daß das
valgrind-Problem an der richtigen Stelle erkannt und dann einfach nach
weiterem Auftreten dieser bestimmten Zeichenfolge im Sourcecode
gesucht wurde. Die kommt nämlich nur genau an diesen beiden Stellen
vor. Das wäre natürlich nicht besser, im Gegenteil ...
> 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.
Und wenn er genauer klargestellt hätte, wo der zweite Codeteil
herkommt, oder daß er der Debian-Maintainer von OpenSSL ist und solche
weitreichenden Änderungen vornehmen will, dann hätte man, so wie es
sich liest, bei dieser FAQ auch mehr Mühe auf die Antwort verwendet.
Offensichtlich hat sich niemand überhaupt genauer angeguckt, wovon er
redet.
> 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).
Ack. Eine fatale Panne.
>> 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.
Okay. Es hängt wohl, soviel habe ich mitgenommen, an der Frage, ob und
wann der DSA/DSS-Key bei der SSH-Authentifizierung zum Signieren
eingesetzt wird. *kopfkratz*
Anyway, das ist doch in jedem Fall nur dann relevant, wenn jemand
einen solchen SSH-Datenverkehr in Kenntnis der Schwachstelle verfolgt
hat, oder ihn mitgeschnitten hat und jetzt darauf untersucht, korrekt?
>> 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.
Okay, das macht Sinn. Kann man also aus meiner Sicht abhaken.
>> 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.
Und bei SSH? Ist der Diffie-Hellman-Schlüsseltausch von einem
schwachen Zufallszahlengenerator auf einer der beiden Seiten
gefährdet?
> 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.
Jetzt muß ich einfach mal blöde fragen: was ist denn im Bereich von
bspw. HTTPS-Verbindungen zwischen "Standardsoftware" (Apache als
Server, IE, Firefox oder Opera als Client) üblich? Welche
Cipher-Suites haben PFS, und woran erkennt man, welche Ciphersuite
verwendet wird? :)
> 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.
Okay. Ich versuche ja auch nur eine einigermaßen brauchbare
Risikoabschätzung.
Grüße,
Roman Racine
> 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
> in der Weise, daß der Server eine Challenge sendet, die er mit dem in
> der authorized_keys hinterlegten Pubkey des Clients verschlüsselt.
Das kann prinzipbedingt bei DSA nicht so gehen, da der Algorithmus im Grunde
genommen nur zum Signieren taugt, nicht zum Verschlüsseln. Ausserdem würde
DSA gar nicht funktionieren, wenn jemand, der nur den Public-Key hat, den
Private-Key irgendwie brechen könnte. Bei DSA muss derjenige, der sich
authentifizieren will eine vom Gegenüber bestimmte Nachricht signieren.
Allerdings muss ich zugeben, dass ich die Protokolldetails, wie
DSA-Authentifikation bei SSH gehandhabt wird und wie der anschliessende
Schlüsselaustausch für den Session-Key stattfindet, auch nicht kenne.
Gruss
Roman°
--
IRC: Freenode, #usenet-friends
Juergen P. Meier
Florian Weimer
> 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?
DSA ist ein Signaturalgorithmus, da kann man nix verschlüsseln.
Florian Weimer
> Lassen sich dann die übertragenen Inhaltsdaten nachträglich
> entschlüsseln, falls der Datenverkehr aufgezeichnet wurde?
Teilweise ja.
> 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.
Bei SSL 3.0 werden die Session-Keys von Zufallszahlen abgeleitet, die
von Client und Server stammen. Wenn bei HTTPS der Client nicht betroffen
ist (z.B. bei Firefox/Iceweasel oder Nicht-Debian-Systemen), dann sollte
aus dem Datenstrom nichts herauszuholen sein.
Marc Haber
>Chris <m...@privacy.net> wrote:
>>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.
... und wäre dort sicher mehr unter den Teppich gekehrt worden.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Florian Weimer
> Ansonsten muss ich bemerken, dass ich als Nicht-Crypto-Experte
> aber als Physiker vor dem Begriff Entropie offensichtlich
> mehr Respekt habe, als der Durchschnittsinformatiker :-/
Es geht schließlich auch um Shannon-Entropie. 8-)
Florian Weimer
> - 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?
Ja.
> Aber: wenn jemand den betreffenden Trafic vorratsgespeichert hat:
>
> * kann er damit direkt etwas anfangen (ist die Authentifizierung
> unverschlüsselt)?
Die Client-Authentifizierung ist verschlüsselt, wenn ich das richtig
sehe, die Server-Authentifizierung nicht.
> * 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)?
Mit dem Bug geht es nur dann, wenn beide Seiten schwache Zufallszahlen
verwenden.
Jens Hektor
> Es geht schließlich auch um Shannon-Entropie. 8-)
AFAIR ging meine DA über simulated annealing 8-)
Michael Ströder
> Michael Ströder <mic...@stroeder.com> wrote:
>> Und überhaupt veraltete Software einzusetzen, welche von den
>> eigentlichen Autoren nicht mehr unterstützt wird, ist keinesfalls
>> "stable". Ach ja...
>>
> das ist dann wie bei cdrecord, oder?
Wenn ein echter Fork von einem aktiven Entwicklerstamm durchgeführt
wird, ist das meines Erachtens kein Problem. Aber ich kenne die aktuelle
Lage bei cdrecord nicht.
Ciao, Michael.
Michael Ströder
> · Well, Michael Ströder <mic...@stroeder.com> wrote:
>> Und überhaupt veraltete Software einzusetzen, welche von den
>> eigentlichen Autoren nicht mehr unterstützt wird, ist keinesfalls
>> "stable".
>
>
> Schau dir mal (z.B.) RHEL 2.1 oder auch nur RHEL 3 an
> [..]
> Das dass nicht immer funktioniert, kann man an aktuellen Samba-Paketen
> für RHEL 4 sehen
Ich habe meine Anmerkungen nicht nur auf Debian bezogen. Den
RHEL-Quatsch schließe ich da explizit mit ein. Die angeblichen
Support-Verträge sind das Papier nicht wert, auf dem sie stehen.
> 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).
Das ist die von Sales-Droiden vermarktete Theorie. Die Praxis sieht
anders aus. Ausbaden müssen dies meist die eigentlichen Entwickler, da
auf deren Mailing-Listen die Anfragen frustrierter Anwender aufschlagen,
trotz Support-Verträgen der kommerziellen Distributoren.
> Dafür muss man sich dann allerdings einen Stamm von Entwicklern leisten
> können und wollen, die wissen, was sie machen.
Was bei vielen kommerziellen Anbietern ebenfalls nicht der Fall ist.
Ciao, Michael.
Andreas Beck
>> 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. Ich hatte eine ganze Horde verwundbarer Keys. Und einen ziemlichen
Hals - besonders nachdem ich mir den verantwortlichen Patch angesehen
hatte.
Ich neige seitdem dazu, denjenigen Recht zu geben, die meinen, dass
OpenSource nix bezüglich Sicherheit bringt, weil es eh niemand anschaut.
CU, ANdy
Thomas Hochstein
> Bei SSL 3.0 werden die Session-Keys von Zufallszahlen abgeleitet, die
> von Client und Server stammen. Wenn bei HTTPS der Client nicht betroffen
> ist (z.B. bei Firefox/Iceweasel oder Nicht-Debian-Systemen), dann sollte
> aus dem Datenstrom nichts herauszuholen sein.
Okay. Danke!
-thh,
vielleicht ist's ja doch für irgendetwas gut, daß Desktop und Laptop
noch unter Windows laufen ;)
Thomas Hochstein
>> - 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?
>
> Ja.
Was dann aber nur relevant ist, wenn ...
>> * 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)?
>
> Mit dem Bug geht es nur dann, wenn beide Seiten schwache Zufallszahlen
> verwenden.
... der Sitzungsschlüssel gebrochen werden kann, weil die
Authentifizierung erst nach der Aushandlung des Sitzungsschlüssels
erfolgt und somit bereits selbst verschlüsselt ist, korrekt? Wenn der
Sitzungsschlüssel gebrochen ist, würde aber auch ein SSH-Paßwort
aufgedeckt sein (und natürlich der ganze Kommunikationsinhalt), oder?
Ist das (hinreichend) sicher, daß der DH-Schlüsselaustausch nur
gebrochen werden kann, wenn *beide* Seiten schwache Zufallszahlen
verwenden?
TIA,
-thh
Thomas Hochstein
> DSA ist ein Signaturalgorithmus, da kann man nix verschlüsseln.
Dann habe ich offensichtlich noch etwas im Hinblick auf den
passwortlosen SSH-Login mit einem DSS/DSA-Key nicht verstanden.
Sebastian G.
> Ich neige seitdem dazu, denjenigen Recht zu geben, die meinen, dass
> OpenSource nix bezüglich Sicherheit bringt, weil es eh niemand anschaut.
Offenbar hat es doch jemand angeschaut, und behoben. Waere es Closed Source,
waere es wohl spaeter oder gar nicht aufgefallen.
Ich neige allerdings zu der Auffassung, dass die originalen Entwickler es
meist deutlich besser wissen als die Forker.
Michael Ströder
>
> Ich neige allerdings zu der Auffassung, dass die originalen Entwickler
> es meist deutlich besser wissen als die Forker.
Genau das ist der Punkt.
Ciao, Michael.
Michael Ströder
>
> Ich neige seitdem dazu, denjenigen Recht zu geben, die meinen, dass
> OpenSource nix bezüglich Sicherheit bringt, weil es eh niemand anschaut.
Du meinst, nur weil dieses Problem jetzt bei Debian sichtbar wurde,
haben kommerzielle Produkte keine solchen Sicherheitsprobleme? Und von
was träumst Du nachts? Immerhin kam es überhaupt raus. Zu spät, aber es
kam raus.
Ciao, Michael.
Andreas Beck
> Andreas Beck wrote:
>> Ich neige seitdem dazu, denjenigen Recht zu geben, die meinen, dass
>> OpenSource nix bezüglich Sicherheit bringt, weil es eh niemand anschaut.
> Offenbar hat es doch jemand angeschaut, und behoben. Waere es Closed Source,
> waere es wohl spaeter oder gar nicht aufgefallen.
Nach 2 Jahren. Da tippe ich fast mal darauf, dass jemand aufgefallen
ist, dass eine Horde seiner Systeme den gleichen SSH-Key hatten, weil
sie ausreichend deterministisch (aka automagisch) installiert wurden.
Hat mich auf meinem FAI-Pool nicht gewundert, weil ich da explizit
gleiche Schlüssel draufkopiere (ich will keine Nervmeldungen nach
jedem Reinstall). Weswegen er auch nicht verwundbar war.
> Ich neige allerdings zu der Auffassung, dass die originalen Entwickler es
> meist deutlich besser wissen als die Forker.
Ja. Diese Beispiel zeigt das deutlich. Ich erinnere mich gut an meine
Worte als ich das SVN-Diff dann im Gesamtfile-Vergleich angeschaut habe
... "Oh Gott ... er hat doch nicht etwa ... autsch".
CU, Andy
Andreas Beck
> Andreas Beck wrote:
>> Ich neige seitdem dazu, denjenigen Recht zu geben, die meinen, dass
>> OpenSource nix bezüglich Sicherheit bringt, weil es eh niemand anschaut.
> Du meinst, nur weil dieses Problem jetzt bei Debian sichtbar wurde,
> haben kommerzielle Produkte keine solchen Sicherheitsprobleme?
Hab ich nicht gesagt. Ich sehe nur keinen Vorteil.
Wenn den Source niemand anschaut, hat man keinen Vorteil.
Und scheinbar schaut ihn niemand an.
Ja, auch ich nicht. Schuldig, Euer Ehren.
> Und von was träumst Du nachts? Immerhin kam es überhaupt raus.
> Zu spät, aber es kam raus.
Nach 2 Jahren ist für _dieses_ Paket und _diesen_ Fehler echt
indiskutabel.
CU, Andy
Ralph Angenendt
> 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.
Dass Ubuntu das unhinterfragt übernommen hat, obwohl das Geld hinter
Ubuntu z.B. für eine etwas striktere QS verwendet werden könnte,
empfinde ich als mindestens genauso schlimm. Na ja, Ubuntu halt.
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/
Bodo Moeller
> Ist das (hinreichend) sicher, daß der DH-Schlüsselaustausch nur
> gebrochen werden kann, wenn *beide* Seiten schwache Zufallszahlen
> verwenden?
Nein! Wer die Zufallszahlen einer Seite erraten kann, kann - genau wie
diese Seite selbst - auch das Resultat des DH-Schlüsselaustauschs
bestimmen.
Florian Weimer
Eh, braucht das wirklich nicht die Kooperation von *beiden* Seiten?
Maik Zumstrull
Man braucht durchaus noch eine Zahl von der anderen Seite -- aber eine,
die unverschlüsselt über die Leitung geht.
Bodo Moeller
Für einen sicheren Schlüsselaustausch braucht jede Seite irgendein
Geheimnis, das in die Schlüsselberechnung eingeht und das der
Angreifer nicht kennt. (Denn sonst kann der alles berechnen, was die
eigentliche Protokollpartei berechnen kann - also auch den
ausgetauschten Schlüssel.)
Dieses Geheimnis kann ein im Vorhinein sicher erzeugter Schlüssel sein,
z.B. ein RSA- oder DH-Schlüssel, der längere Zeit verwendet wird.
Wenn eine Partei im Schlüsselaustausch einen frisch erzeugten
DH-Schlüssel verwendet und sonst kein relevantes Geheimnis hat,
dann muß dieser frisch erzeugte Schlüssel unvorhersehbar sein;
sonst kann sich der Angreifer in diese Seite hineinversetzen und
alle kryptographischen Berechnungen nachvollziehen.
Bernd Kreuss
> Sobald der
> DSS-Schlüssel *einmal* mit einem schlechten Zufallszahlengenerator zum
> Signieren eingesetzt wird, ist er also potentiell gebrochen.
Das führt mich direkt zur nächsten Frage:
Kommt der hier angesprochene Mechanismus auch zum Einsatz, wenn eine Root-
CA ein Zertifikat für ein Stück Software, beispielsweise ein Active-X-
Control signiert? Könnte man ein in der Zertifikatshierarchie weit oben
stehendes Zertifikat fälschen wenn der Besitzer des Zertifikats damit
irgendwann einmal ein Stück Software oder ein anderes Zertifikat auf
einer betroffenen Debian Kiste signiert hat?
Bernd
--
private communication within hostile networks:
http://torchat.googlecode.com/
Tobias Barth
> 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?
Nein, es liegt eher daran, dass die Admins dieser Welt seit 3 Tagen nur noch am Schlüssel-Tauschen und Pakete-Updaten sind...
Ciao
Tobi
Richard W. Könning
>Richard W. Könning wrote:
>
>
>>> 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.
Wenn Du bei diesem Link auf die nächste Message weitergescrollt
hättest, dann hättest Du sofort gesehen, wovon in diesem Thread, im
Heise-Newsticker und sonstwo auf der Welt die Rede ist. Warum hast Du
das nicht getan? Ist das soviel Arbeit? Ist es insbesondere weniger
Arbeit, als einen Haufen Postings zu verfassen, die am Thread-Topic
vorbeigehen?
Ciao,
Richard
--
Dr. Richard Könning Heßstraße 63
Tel.: 089/5232488 80798 München
Richard W. Könning
>Richard W. Könning <Richard....@t-online.de> wrote:
>>Chris <m...@privacy.net> wrote:
>>>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.
>
>... und wäre dort sicher mehr unter den Teppich gekehrt worden.
Vielleicht, vielleicht auch nicht. Intel z.B. hat auf die harte Tour
gelernt, daß unter den Teppich kehren nicht immer umsonst ist. Andere
Firmen haben schon mal ähnliche Erfahrungen gemacht. Wie daher eine
konkrete Firma in einem konkreten Fall handeln würde, wage ich nicht
zu prognostizieren.
Richard W. Könning
>Bodo Moeller wrote:
>
>> 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.
Kauf Dir ein Scrollrad für Deine Maus :-).
Richard W. Könning
>Andreas Beck wrote:
>>
>> Ich neige seitdem dazu, denjenigen Recht zu geben, die meinen, dass
>> OpenSource nix bezüglich Sicherheit bringt, weil es eh niemand anschaut.
>
>Du meinst, nur weil dieses Problem jetzt bei Debian sichtbar wurde,
>haben kommerzielle Produkte keine solchen Sicherheitsprobleme? Und von
Andreas hat keineswegs behauptet, daß kommerzielle Produkte keine
Sicherheitsprobleme hätten. Er hat nur festgestellt, daß der
postulierte Vorteil des Viele-Augen-Prinzips bei OpenSource faktisch
nicht existent ist. Eine Feststellung, für die er leider kein
Urheberrecht beanspruchen kann, da schon eine Reihe anderer Leute vor
ihm zum gleichen Schluß gekommen ist.
Ein Blick in den Mail-Reader @work gestern zeigte, daß auch ich den
besagten Thread auf openssl-dev damals gelesen habe. Aber offenbar war
ich nicht unbeschäftigt genug, um mal eben im Source nachzuschauen.
>was träumst Du nachts? Immerhin kam es überhaupt raus. Zu spät, aber es
Es gibt keinen Grund, Andreas dumm anzumachen. Zwei Jahre unterwegs
faktisch ohne einen PRNG sind eine verdammt lange Zeit...
>kam raus.
..., da braucht man nicht noch stolz darauf zu sein, daß es doch noch
herauskam.
Florian Weimer
> Juergen P. Meier schrieb:
>
>> Der Session-Key fuer die symmetrische Verschluesselung der Datenpakete
>> (AES/3DES) wird verschluesselt und signiert -> Peng.
Das stimmt für SSH nicht.
> Mit dem Schlüssel, der auch für den SSH-Key-Auth verwendet wird? :-O
Es wird u.a. auch die Session-ID ID signiert, die vorher über einen
DH-Schlüsseltausch aufgesetzt wurde (und ein Hash u.a. über den
Session-Key ist).
> Und mit was wird verschlüsselt und signiert, wenn password based
> authentification verwendet wird? *kopfkratz*
Es wird gar nix signiert. Der Client schickt das Paßwort über den
verschlüsselten Kanal, und das war's.
(Bei Protokollversion 1 mag alles ganz anders sein.)
Florian Weimer
>> Eh, braucht das wirklich nicht die Kooperation von *beiden* Seiten?
>
> Man braucht durchaus noch eine Zahl von der anderen Seite -- aber eine,
> die unverschlüsselt über die Leitung geht.
Oh, natürlich.
Richard W. Könning
>* Andreas Beck <becka-news-n...@bedatec.de> schrieb:
>
>> Ich neige seitdem dazu, denjenigen Recht zu geben, die meinen, dass
>> OpenSource nix bezüglich Sicherheit bringt, weil es eh niemand
>> anschaut.
>
>Bei einem Closed-Source-Hersteller hätte es sicherlich Bestrebungen
>gegeben, die Sache zu vertuschen. :->
Wie ein Unternehmen reagiert, wird man jeweils im konkreten Fall
beurteilen müssen. Intel z.B. hat sich nach seinem Pentium-Fehler als
durchaus lernfähig erwiesen. Es gibt in der jetzigen Situation keinen
Grund, auf Closed-Source-Hersteller zu zeigen.
Richard W. Könning
>Richard W. Könning schrieb:
>
>> 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).
>
>Ich halte es auch für nicht völlig auszuschließen, daß das
>valgrind-Problem an der richtigen Stelle erkannt und dann einfach nach
>weiterem Auftreten dieser bestimmten Zeichenfolge im Sourcecode
>gesucht wurde. Die kommt nämlich nur genau an diesen beiden Stellen
>vor. Das wäre natürlich nicht besser, im Gegenteil ...
Ich habe keine praktischen Erfahrungen mit valgrind, vermute aber, daß
das Tool (zumindestens damals) Fehler an der Stelle anzeigt, wo auf
nicht initialisierte Datenbereiche zugegriffen wird, und das ist nun
mal die Stelle in der ssleay_rand_add-Funktion. Es ist dann Aufgabe
des Tool-Nutzers, festzustellen, wie es dazu kommt, daß an dieser
Stelle ein nicht-initialisierter Datenbereich vorhanden ist. Das macht
natürlich Arbeit, und wenn man sich diese spart, dann kann es schon
mal zu Unfällen kommen.
>> 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.
>
>Und wenn er genauer klargestellt hätte, wo der zweite Codeteil
>herkommt, oder daß er der Debian-Maintainer von OpenSSL ist und solche
Wie ich schon schrieb (s.u.), einzelne Codezeilen ohne Kontext, ohne
die umschließende Funktion anzugeben, war nicht sonderlich klug.
Ein Problem war, daß man ihm seine Behauptung, daß an beiden Stellen
nur nicht-initialisierte Speicherbereiche an den PRNG übergeben
werden, ungeprüft übernommen hat. Hätte er sich als Debian-Maintainer
von OpenSSL geoutet, dann hätte man ihm (damals) diese Behauptung
vermutlich noch eher abgenommen, in der Erwartung, daß er weiß, wovon
er redet. Heute wird das vermutlich anders sein ;-).
>weitreichenden Änderungen vornehmen will, dann hätte man, so wie es
>sich liest, bei dieser FAQ auch mehr Mühe auf die Antwort verwendet.
>Offensichtlich hat sich niemand überhaupt genauer angeguckt, wovon er
>redet.
Wozu? Er hat den Eindruck gemacht, als ob er wüßte, wovon er redet,
und ihm nur unklar war, wie relevant der Entropiebeitrag der
uninitialisierten Speicherbereiche ist. Und auf letzteres hat man ihm
korrekt geantwortet: Nice to have, aber nicht wirklich notwendig.
Wer openssl-dev und openssl-user abonniert hat (wie ich) und von daher
das Nachrichtenaufkommen bzgl. Quantität und Qualität kennt und
andererseits abschätzen kann, daß keiner der OpenSSL-Entwickler sich
über längere Zeit hauptberuflich mit OpenSSL beschäftigen kann, der
wird verstehen, daß nicht jede Anfrage mit einer tiefschürfenden
Code-Analyse beantwortet wird. Wer einen solchen Anspruch hat, der muß
halt mit entsprechender Finanzierung daherkommen.
Und es geht schließlich um OpenSource: Um zu erkennen, daß er Unsinn
veranstaltet, hätte der Fragesteller nur C-Kenntnisse und ein gewisses
Maß an Pedanterie gebraucht, detailliertere kryptografische Kenntnisse
waren gar nicht notwendig.
>>> 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.
>
>Okay. Es hängt wohl, soviel habe ich mitgenommen, an der Frage, ob und
>wann der DSA/DSS-Key bei der SSH-Authentifizierung zum Signieren
>eingesetzt wird. *kopfkratz*
>
>Anyway, das ist doch in jedem Fall nur dann relevant, wenn jemand
>einen solchen SSH-Datenverkehr in Kenntnis der Schwachstelle verfolgt
>hat, oder ihn mitgeschnitten hat und jetzt darauf untersucht, korrekt?
Äh, das ist doch schon der schlimmstmögliche Fall, wieso daher "nur
dann"?
>>> 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.
>
>Und bei SSH? Ist der Diffie-Hellman-Schlüsseltausch von einem
>schwachen Zufallszahlengenerator auf einer der beiden Seiten
>gefährdet?
Da das gemeinsame Geheimnis jeweils aus dem privaten Schlüssel der
einen und dem öffentlichen Schlüssel der anderen Seite berechnet wird,
reicht ein schwacher PRNG auf einer Seite für eine Gefährdung.
>> 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.
>
>Jetzt muß ich einfach mal blöde fragen: was ist denn im Bereich von
>bspw. HTTPS-Verbindungen zwischen "Standardsoftware" (Apache als
>Server, IE, Firefox oder Opera als Client) üblich? Welche
EDH ist teuer bzgl. CPU-Zyklen. Es kommt also darauf an, wieviel der
Server-Betreiber zu spendieren bereit ist.
>Cipher-Suites haben PFS, und woran erkennt man, welche Ciphersuite
>verwendet wird? :)
Je nach Nomenklatur sind das Suites mit einem "EDH" oder "DHE" im
Namen. Bei Firefox about:config als URL eingeben und dann nach
security.ssl3.* suchen, dort gibt es z.B.
security.ssl3.dhe_dss_aes_128_sha und weitere ssl3.dhe*-Cipher-Suites.
Der Firefox zeigt beim Klick auf das Schloß unter anderem eine
Ciphersuite-Bezeichnung an, läßt aber dabei zumindestens bei RSA die
Bezeichnung für den Public-Key-Teil weg (also bei
https://www.telekom.de nur AES-256). Ob das bei EDH anders ist, weiß
ich nicht, da ich auf die Schnelle keinen Server mit EDH kenne (evtl.
komme ich im Laufe des Tages noch dazu, den Apache anzuwerfen, dann
kann ich es lokal ausprobieren).
Roman Racine
> 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 führt mich direkt zur nächsten Frage:
>
> Kommt der hier angesprochene Mechanismus auch zum Einsatz, wenn eine Root-
> CA ein Zertifikat für ein Stück Software, beispielsweise ein Active-X-
> Control signiert? Könnte man ein in der Zertifikatshierarchie weit oben
> stehendes Zertifikat fälschen wenn der Besitzer des Zertifikats damit
> irgendwann einmal ein Stück Software oder ein anderes Zertifikat auf
> einer betroffenen Debian Kiste signiert hat?
Wenn der DSS-Algorithmus mit einem schwachen PRNG zur Anwendung gekommen
ist, kann man das, ja.
Sofern mit dem RSA-Algorithmus signiert worden ist, kann man das nicht, da
dieser nicht auf einen kryptografisch sicheren PRNG angewiesen ist.
Andererseits sind mit Debian erstellte SSL-Keys generell unsicher, egal, ob
es nun RSA oder DSA-Keys sind. Bisher ist mir noch kein Update bekannt,
welches z.B. davon betroffene Webserverzertifikate automatisch als ungültig
betrachten und den User warnen würde.
Gruss
Roman°
--
IRC: Freenode, #usenet-friends
Richard W. Könning
>Florian Weimer schrieb:
>
>> Bei SSL 3.0 werden die Session-Keys von Zufallszahlen abgeleitet, die
>> von Client und Server stammen. Wenn bei HTTPS der Client nicht betroffen
>> ist (z.B. bei Firefox/Iceweasel oder Nicht-Debian-Systemen), dann sollte
>> aus dem Datenstrom nichts herauszuholen sein.
>
>Okay. Danke!
>
>-thh,
>vielleicht ist's ja doch für irgendetwas gut, daß Desktop und Laptop
>noch unter Windows laufen ;)
Ich muß Dich leider enttäuschen, siehe meine Antwort auf Florian.
Richard W. Könning
>* Thomas Hochstein:
>
>> Lassen sich dann die übertragenen Inhaltsdaten nachträglich
>> entschlüsseln, falls der Datenverkehr aufgezeichnet wurde?
>
>Teilweise ja.
>
>> 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.
>
>Bei SSL 3.0 werden die Session-Keys von Zufallszahlen abgeleitet, die
>von Client und Server stammen. Wenn bei HTTPS der Client nicht betroffen
>ist (z.B. bei Firefox/Iceweasel oder Nicht-Debian-Systemen), dann sollte
>aus dem Datenstrom nichts herauszuholen sein.
Vorsicht: Die oben genannten Zufallszahlen werden im *Klartext*
übertragen. Zusätzlich geht ein mit dem RSA-Key des Servers
verschlüsseltes Premaster-Secret ein (bei DH ein gemeinsam
vereinbartes Premaster-Secret), wenn also der PRNG des Servers
betroffen ist, dann hat man die A-Karte gezogen.
Florian Weimer
> Vorsicht: Die oben genannten Zufallszahlen werden im *Klartext*
> übertragen. Zusätzlich geht ein mit dem RSA-Key des Servers
> verschlüsseltes Premaster-Secret ein (bei DH ein gemeinsam
> vereinbartes Premaster-Secret), wenn also der PRNG des Servers
> betroffen ist, dann hat man die A-Karte gezogen.
Ja,ich hatte Blödsinn geschrieben. Da ich an Abhörem im Internet durch
Unbefugte nicht glaube, mache ich mir darum leider nicht so große
Gedanken. 8-/
Arno Welzel
> Bernd Kreuss wrote:
>
>
>> 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.
Ja, darum geht es. Nur die Auswirkungen des Fixes dazu hast Du offenbar
nicht wahrgenommen.
Arno Welzel
Man sollte es anders formulieren: Nur die Tatsache, dass etwas als
OpenSource umgesetzt wird, bedeutet nicht, dass es automatisch sicherer
wäre, auch wenn man annehmen kann, dass offener Quellcode von mehr
Leuten geprüft wird, als Closed Source.
Ein Code-Review hilft erst dann etwas, wenn er von den Leuten gemacht
wird, die auch korrekt einschätzen, was Änderungen bewirken, egal ob
eine Community oder Leute aus dem Entwickler-Kreis einer Firma. Hier hat
das ganz offensichtlich nicht geklappt - jemand hat im Debian-Fork etwas
committed, niemand hat gesehen, was dadurch eigentlich kaputt geht und
so wurde zwei Jahre lang nichts daran gemacht - und das obwohl die
Quellen zwei Jahre lang für Jeden einsehbar waren.
Richard W. Könning
>Michael Ströder schrieb:
>
>> Andreas Beck wrote:
>>>
>>> Ich neige seitdem dazu, denjenigen Recht zu geben, die meinen, dass
>>> OpenSource nix bezüglich Sicherheit bringt, weil es eh niemand anschaut.
>>
>> Du meinst, nur weil dieses Problem jetzt bei Debian sichtbar wurde,
>> haben kommerzielle Produkte keine solchen Sicherheitsprobleme? Und von
>> was träumst Du nachts? Immerhin kam es überhaupt raus. Zu spät, aber es
>> kam raus.
>
>Man sollte es anders formulieren: Nur die Tatsache, dass etwas als
>OpenSource umgesetzt wird, bedeutet nicht, dass es automatisch sicherer
>wäre, auch wenn man annehmen kann, dass offener Quellcode von mehr
>Leuten geprüft wird, als Closed Source.
Wieso kann man das annehmen? Der vorliegende Unfall zeigt, daß man das
eben nicht so einfach annehmen kann.
>Ein Code-Review hilft erst dann etwas, wenn er von den Leuten gemacht
>wird, die auch korrekt einschätzen, was Änderungen bewirken, egal ob
>eine Community oder Leute aus dem Entwickler-Kreis einer Firma. Hier hat
>das ganz offensichtlich nicht geklappt - jemand hat im Debian-Fork etwas
>committed, niemand hat gesehen, was dadurch eigentlich kaputt geht und
>so wurde zwei Jahre lang nichts daran gemacht - und das obwohl die
>Quellen zwei Jahre lang für Jeden einsehbar waren.
Eben. Code-Review ist Arbeit, die entweder gemacht wird oder eben
nicht. Wird sie nicht gemacht, dann unterscheidet sich OpenSource
bzgl. Sicherheit kaum von Closed Source. OpenSource hat durchaus ihre
Meriten, aber daß sie im Mittel besser gereviewed wird, gehört imho
ins Märchenreich. Und ich muß Ben Laurie recht geben, daß es die Sache
nicht verbessert, wenn jede Distribution meint, ihr eigenes Süppchen
kochen zu müssen, weil dann nicht nur eine OpenSSL-Variante geprüft
werden muß, sondern ein ganzer Haufen.