Was heisst das jetzt fürs Internet? Dort gibt es doch auch SSL verschlüsselte Seiten. Werden diese Schlüssel bei jedem zugriff erneuert, oder hat das gar nichts mit openSSL zu tun?
Das könnte ein GAU werden. Damit werden komplette PKI zerstört. Größere Unternehmen werden Wochen, wenn nicht Monate brauchen, um die Schlüssel zu erneuern. Man denke nur an die ganzen Road-Warrior die mit ihren Schlüsseln auf den Notebooks unterwegs sind und an die man erstmal nicht rankommt. Klar kann man die Keys revoken, aber das Theater möchte ich nicht erleben, wenn die Außendienstler erstmal nicht mehr arbeiten können. Chefs mit weniger Verständnis könnten dann dafür sorgen, dass in der IT-Abteilung erstmal Köpfe rollen.
Übrigens funktioniert das Perl-Script bei mir nicht: dowkd.pl file ca.key ca.key:1: warning: unparsable line ca.key:2: warning: unparsable line [... mehr unparsable line warnings ...]
Von Christoph Bartoschek am Mi, 14. Mai 2008 um 09:53 #
Openssl hat sich hier richtig verhalten. Die Entropie aus dem uninitialisierten Speicher hilft zwar nicht, aber sie schadet nicht und ist kostenlos. Es ist sogar teurer den Puffer für die Zufallszahlen erst mit 0 zu füllen.
Für Leute, die ihre Programme debuggen müssen, und Valgrind verwenden möchten, das über den uninitialisierten Speicher meckert, köhnnen einfach das Makro PURIFY beim Kompilieren setzen und der uninitialisierte Speicher wird nicht verwendet.
Ohjeeee! Eine wirklich kritische Angelegenheit - wenn sogar Ubuntu einen Bugfix *kurzfristig* ins Repo aufnimmt. Oder ist es mit tollen grafischen Spielereien verknüpft??
Ich habe allerlei Weak Keys in meiner known_hosts (dowkd.pl file /usr/oms/.ssh/known_hosts). Da diese gehasht ist, muß ich wahrscheinlich alle paar hundert Einträge per Hand 'abtelefonieren'. Oder kennt jemand eine clevere Methode, wie ich die betroffenen Hosts direkt aus der known_hosts ableiten kann ?
Der Patch wurde durchaus mit den Entwicklern von OpenSSL diskutiert.
Der Debian Maintainer stellt in seiner Mail an die Entwicklerliste fest, dass er sich nicht endgültig sicher ist, welche Auswirkungen die Verwendung oder Nicht-Verwendung von uninitialisiertem Speicher als Entropiequelle hat. Er liefert einen Patch, in dem er vorschlägt, zwei Zeilen aus dem LibSSL Sourcecode zu löschen. Leider betrifft davon nur eine die Verwendung des uninitialisiten Speichers, die andere (als Zeile gleichlautende) führt das Sicherheitsproblem ein, um das es hier geht. http://marc.info/?l=openssl-dev&m=114651085826293&w=2
Ein OpenSSL Entwickler antwortet darauf, dass die Auswirkungen gering sind und er durchaus bereit wäre, die fraglichen Zeilen aus dem Code herauszunehmen. http://marc.info/?l=openssl-dev&m=114652287210110&w=2 Er hat offensichtlich übersehen, dass der vorgeschlagene Patch mehr als nur das kritisierte Problem "behebt".
Savannah hat da sehr schnell reagiert und befallene Schlüssel sofort deaktiviert. Ich hatte Mail von denen noch bevor ich das in den News gelesen hatte.
Ich hatte ich zwei Schlüssel und tatsächlich wurde nur der deaktiviert, den ich unter Etch erstellt hatte. Den anderen hatte ich noch unter Sarge erstellt.
Weiss jemand, ob man auch die Hostkeys neu machen sollte? Gibt's dazu bei Debian einen Befehl? Das hier sollte eigentlich funktionieren. ssh-keygen -b 1024 -f /etc/ssh_host_key -N ''
Ich glaube der Titel sagt schon alles, für mich wäre noch wichtig zu wissen das was nun Konkret für einen Angreifer bedeutet. Auf der Debian Seite schreiben die ja dass ein Bruteforceangriff möglich wäre da es nur irgendwelche hundertausende Möglichkeiten. Wie leicht ist das nun für einen Angreiffer? Zum Verständnis ich will keine Angriffe durchführen sondern will dies wissen damit ich weiss um welche Systeme ich mich zuerst kümmern muss. gruss
Weiß jemand die Ausgabe des Skripts zu interpretieren? Hier hat ein User gepostet, was er ausgibt, wenn er lokale weak keys findet. Weiß jemand, wie es auszusehen hat, wenn er remote keys der einen oder anderen Art findet? Ich bekomme
Ich finde wir sollte diesen Debian-GAU (und es ist nichts geringeres) nicht als Katastrophe, sondern als Chance ansehen, unsere Stärken zu demonstrieren.
In einer Monokultur (=Microsoft) wäre das der absolute Weltuntergang, in der bunten Welt der freien Software ist es ein gefährliches, aber nicht lebensbedrohendes, Problem, das gelöst werden wird. Und es wird genug Linux/BSD-Administratoren geben, die sagen... "Hmmm, dumm gelaufen für die armen Debian/Ubuntu-Admins, ich trinke erst einen Kaffee und frage dann mal wo ich helfen kann..."
Es ist ein großer Vorteil der Vielfalt der freien Betriebssysteme, dass ein solches Problem nicht auf alle durchschlägt. Jeder der sagt, "Es gibt zu viel Auswahl! Das verwirrt die Benutzer, deshalb wird Linux NIEMALS ein Betriebssystem für die Massen..." sollte sich das, was hier passiert ist mal unter Windows oder einem "Einheitslinux" vorstellen.
Wunderschönen Nachmittag noch, ich verwende übrigens Slackware...
Von Crass Spektakel am Mi, 14. Mai 2008 um 16:30 #
Anscheinend sind meine Keys zu alt, die sind restlos alle in Ordnung, das Tool findet keine schlechten Keys, auf dutzenden von Rechnern. Alle generiert mit Ubuntu 6.06 bzw. noch auf SuSE 7.3.
Okay, also Malheur ist passiert, SuperGAU eingetreten. Dumm gelaufen, nicht mehr zu ändern. Die Schlüssel zu tauschen hab ich auch grade noch geschafft, wirklich beruhigt bin ich dadurch nun aber nicht.
Um mal Klartext zu reden: mein Server (und mit ihm etliche tausend andere) waren zwei Jahre lang relativ einfach aufzumachen, jegliche Kommunikation über SSL-gesicherte Verbindungen relativ einfach mitzulesen. Es wäre wohl auch blauäugig zu glauben, niemand hätte diese Lücke schon früher gekannt.
Ich kann mir nicht einmal ausmalen, was in diesen zwei Jahren alles passiert sein mag. Von rootkit über entschlüsseln allen VPN-Traffics ...
Einfach auf Debian draufzuhauen hilft ja nix, es ändert nichts an der Situation.
Welche Angriffszenarien sind hier möglich gewesen? Fühle ich mich vielleicht zu unrecht wie nackt?
Man sollte dazuschreiben, dass kompromittierte Host-Keys beim Upgrade (apt-get update; apt-get dist-upgrade) eines Debian-Systems immerhin automatisch erkannt und ersetzt werden, mit einer entsprechenden Meldung.
Betrifft das jetzt auch die ssl-Verschlüsselung im Browser? Wenn ja, was mache ich dagegen? Ich nutze z.B. Iceweasel zum Onlinebanking und möchte auf der sicheren Seite sein.
Debian ist was es ist und was es die letzten Jahre gewesen ist, eine spitzen Distribution. Ich käme nicht im Traum darauf, jetzt wegen diesem Fehler - der zugegenermaßen ein gewisses Ausmaß hat - tausende von Leuten zu beleidigen. Das steht einfach in keinem Verhältnis zu dem was hier insgesamt geleistet wird. Nicht zuletzt haben wir es mit einer kompletten Offenheit im Umgang mit diesem Fehler zu tun. Ein hoch auf Debian.
Warum wurde die Entropie nicht mit Hilfe von /dev/random (oder urandom -ich meine die blockierende Variante) erhöht? Mir scheint uninitialisierer Speicher wenn er auch besser als garnichts ist die falscheste (ich weiss falsch lässt sich nicht steigern außer für schlechte Witze) Lösung für das Problem zu sein Zufallszahlen zu erhalten, über diesen lässt sich keine Aussage treffen weder ob dort zufälliges drin steht noch ob dort zufällig immer das gleiche steht weil in einem script zuvor immer das gleiche programm ausgeführt wurde und eben dessen speicher jedes mal weiter verwendet wird.
Die Korrektur dieses Fehlers erfolgte an zwei Stellen, eine davon war fehlerhaft.
Keine einzige Stelle war fehlerhaft, sondern ein Tool namens valgrind war fehlerhaft, welches der Debian-Maintainer Kurt Roeckx benutzte. Er wurde auf der OpenSSL-Mailingliste auch auf diesen Umstand hingewiesen.
(However the last time I checked, valgrind reported thousands of bogus error messages. Has that situation gotten better?) -- Ulf Möller
Obwohl die Korrektur öffentlich und auch auf der OpenSSL-Mailingliste diskutiert wurde, wurde der Fehler nicht erkannt.
Das ist unwahr, diskutiert wurde vielmehr folgendes:
When debbuging applications that make use of openssl using valgrind, it can show alot of warnings about doing a conditional jump based on an unitialised value. -- Kurt Roeckx
Der Debian-Maintainer Kurt Roeckx hat sich weder als solcher zu erkennen gegeben, noch erwähnt, daß seine Änderungen in das OpenSSL-Paket in Debian GNU/Linux 4.0 einfließen werden.
Alles nachzulesen hier:
http://marc.info/?t=114651088900003&r=1&w=2
In die Kritik gerät allerdings auch OpenSSL selbst. Deren Code versucht, die Entropie des Zufallsgenerators zu erhöhen, indem Zufallszahlen aus verschiedenen Quellen hinzugefügt werden. Eine dieser Quellen ist eine Bytefolge, die an einer Stelle lediglich auf »nicht initialisierten« Speicher verweist.
Das ebenfalls unwahr. Hier wiederholt Pro-Linux nur den Irrtum von Kurt Roeckx. OpenSSL verwendet nirgendwo uninitialisierten Speicher zur Initialisierung des Zufallsgenerators.
Die Postings von Kurt Roeckx auf debian-dev waren äußerst merkwürdig. - Er gab sich nicht als Debian-Maintainer zu erkennen - Er gab sich harmlos-naiv bezüglich der Auswirkungen des "Bugfixes", was im krassen Widerspruch zu seiner Funktion als Maintainer eines sicherheitskritischen Pakets steht. Würden sich bei Debian n00bs mit Security-Paketen beschäftigen, wäre dies automatisch ein K.O.-Kriterium für diese und alle abgeleiteten Distributionen.
Ich gehe davon aus, dass der Mann genau wußte, was er tat, als er Entropie aus einem RNG herausnahm. Ihm musste auch bewusst sein, dass alle Pakete, die auf OpenSSL zurückgreifen, davon betroffen sind.
Es scheint, als wollte er lediglich ein paar harmlose Antworten der OpenSSL-Entwickler provozieren, um seinen "Patch" zu legitimieren. So abgesichert, wollte das dann keiner mehr hinterfragen, und er pflegte den Patch mit einem unauffälligen Kommentar ein.
Offenbar interessiert es niemanden, ob diese verheerende Änderung vielleicht absichtlich geschehen konnte. Die Story von wegen valgrind-Errors ist völlig unglaubwürdig.
Es wäre jedenfalls interessant zu wissen, wo dieser Herr noch überall seine Finger im Spiel hat. Wer weiß, vielleicht pflegt er ja noch ein paar sicherheitskritische Pakete, wo weitere Backdoors ihrer Entdeckung harren?
Und kanzelt mich bitte nicht mit "Verschwörungstheoretiker" ab. Die ganze Story stinkt gewaltig nach Manipulation.
A big part of your job as Debian maintainer will be to stay in contact with the upstream developers. Debian users will sometimes report bugs that are not specific to Debian to our bug tracking system. You have to forward these bug reports to the upstream developers so that they can be fixed in a future upstream release.
While it's not your job to fix non-Debian specific bugs, you may freely do so if you're able. When you make such fixes, be sure to pass them on to the upstream maintainers as well. Debian users and developers will sometimes submit patches to fix upstream bugs — you should evaluate and forward these patches upstream.
If you need to modify the upstream sources in order to build a policy compliant package, then you should propose a nice fix to the upstream developers which can be included there, so that you won't have to modify the sources of the next upstream version. Whatever changes you need, always try not to fork from the upstream sources."
Eindeutiger geht es wohl nicht: "When you make such fixes, be sure to pass them on to the upstream maintainers as well." Die strikte Befolgung dieser Guidelines hätte wohl den Debian-Openssl-Bug schon zu Beginn verhindert.
Dort gibt es doch auch SSL verschlüsselte Seiten.
Werden diese Schlüssel bei jedem zugriff erneuert,
oder hat das gar nichts mit openSSL zu tun?
Schlüssel zu erneuern. Man denke nur an die ganzen Road-Warrior die mit ihren Schlüsseln auf den Notebooks unterwegs sind und an die man erstmal nicht rankommt. Klar kann man die Keys revoken, aber das Theater möchte ich nicht erleben, wenn die Außendienstler erstmal nicht mehr arbeiten können. Chefs mit weniger Verständnis könnten dann dafür sorgen, dass in der IT-Abteilung erstmal Köpfe rollen.
Übrigens funktioniert das Perl-Script bei mir nicht:
dowkd.pl file ca.key
ca.key:1: warning: unparsable line
ca.key:2: warning: unparsable line
[... mehr unparsable line warnings ...]
Für Leute, die ihre Programme debuggen müssen, und Valgrind verwenden möchten, das über den uninitialisierten Speicher meckert, köhnnen einfach das Makro PURIFY beim Kompilieren setzen und der uninitialisierte Speicher wird nicht verwendet.
Da diese gehasht ist, muß ich wahrscheinlich alle paar hundert Einträge per Hand 'abtelefonieren'.
Oder kennt jemand eine clevere Methode, wie ich die betroffenen Hosts direkt aus der known_hosts ableiten kann ?
So ein Schiet!
Der Debian Maintainer stellt in seiner Mail an die Entwicklerliste fest, dass er sich nicht endgültig sicher ist, welche Auswirkungen die Verwendung oder Nicht-Verwendung von uninitialisiertem Speicher als Entropiequelle hat. Er liefert einen Patch, in dem er vorschlägt, zwei Zeilen aus dem LibSSL Sourcecode zu löschen. Leider betrifft davon nur eine die Verwendung des uninitialisiten Speichers, die andere (als Zeile gleichlautende) führt das Sicherheitsproblem ein, um das es hier geht.
http://marc.info/?l=openssl-dev&m=114651085826293&w=2
Ein OpenSSL Entwickler antwortet darauf, dass die Auswirkungen gering sind und er durchaus bereit wäre, die fraglichen Zeilen aus dem Code herauszunehmen.
http://marc.info/?l=openssl-dev&m=114652287210110&w=2
Er hat offensichtlich übersehen, dass der vorgeschlagene Patch mehr als nur das kritisierte Problem "behebt".
Ich hatte ich zwei Schlüssel und tatsächlich wurde nur der deaktiviert, den ich unter Etch erstellt hatte. Den anderen hatte ich noch unter Sarge erstellt.
https://savannah.gnu.org/forum/forum.php?forum_id=5321
Weiss jemand, ob man auch die Hostkeys neu machen sollte? Gibt's dazu bei Debian einen Befehl? Das hier sollte eigentlich funktionieren.
ssh-keygen -b 1024 -f /etc/ssh_host_key -N ''
Nicht vergessen erst das Update einzuspielen!
Zum Verständnis ich will keine Angriffe durchführen sondern will dies wissen damit ich weiss um welche Systeme ich mich zuerst kümmern muss.
gruss
$ perl dowkd.pl host xy.de
# xy SSH-2.0-OpenSSH_4.3p2 Debian-9
# xy SSH-2.0-OpenSSH_4.3p2 Debian-9
$ perl dowkd.pl host localhost
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9etch1
# localhost SSH-2.0-OpenSSH_4.3p2 Debian-9etch1
Heißt das jetzt vulnerable oder nicht? Hat jemand "eindeutige" Outputs zum Gegenchecken?
Ich finde wir sollte diesen Debian-GAU (und es ist nichts geringeres) nicht als Katastrophe, sondern als Chance ansehen, unsere Stärken zu demonstrieren.
In einer Monokultur (=Microsoft) wäre das der absolute Weltuntergang, in der bunten Welt der freien Software ist es ein gefährliches, aber nicht lebensbedrohendes, Problem, das gelöst werden wird.
Und es wird genug Linux/BSD-Administratoren geben, die sagen... "Hmmm, dumm gelaufen für die armen Debian/Ubuntu-Admins, ich trinke erst einen Kaffee und frage dann mal wo ich helfen kann..."
Es ist ein großer Vorteil der Vielfalt der freien Betriebssysteme, dass ein solches Problem nicht auf alle durchschlägt.
Jeder der sagt, "Es gibt zu viel Auswahl! Das verwirrt die Benutzer, deshalb wird Linux NIEMALS ein Betriebssystem für die Massen..." sollte sich das, was hier passiert ist mal unter Windows oder einem "Einheitslinux" vorstellen.
Wunderschönen Nachmittag noch, ich verwende übrigens Slackware...
Dangerseeker
http://www.golem.de/0805/59671.html
Auch ich werde die Distro wechseln, wahrscheinlich werde ich sogar auf ein *BSD umsteigen.
The Emperor has no clothes.
Um mal Klartext zu reden: mein Server (und mit ihm etliche tausend andere) waren zwei Jahre lang relativ einfach aufzumachen, jegliche Kommunikation über SSL-gesicherte Verbindungen relativ einfach mitzulesen. Es wäre wohl auch blauäugig zu glauben, niemand hätte diese Lücke schon früher gekannt.
Ich kann mir nicht einmal ausmalen, was in diesen zwei Jahren alles passiert sein mag. Von rootkit über entschlüsseln allen VPN-Traffics ...
Einfach auf Debian draufzuhauen hilft ja nix, es ändert nichts an der Situation.
Welche Angriffszenarien sind hier möglich gewesen? Fühle ich mich vielleicht zu unrecht wie nackt?
Mir scheint uninitialisierer Speicher wenn er auch besser als garnichts ist die falscheste (ich weiss falsch lässt sich nicht steigern außer für schlechte Witze) Lösung für das Problem zu sein Zufallszahlen zu erhalten, über diesen lässt sich keine Aussage treffen weder ob dort zufälliges drin steht noch ob dort zufällig immer das gleiche steht weil in einem script zuvor immer das gleiche programm ausgeführt wurde und eben dessen speicher jedes mal weiter verwendet wird.
Keine einzige Stelle war fehlerhaft, sondern ein Tool namens valgrind war fehlerhaft, welches der Debian-Maintainer Kurt Roeckx benutzte. Er wurde auf der OpenSSL-Mailingliste auch auf diesen Umstand hingewiesen.
(However the last time I checked, valgrind reported thousands of bogus error messages. Has that situation gotten better?) -- Ulf Möller
Obwohl die Korrektur öffentlich und auch auf der OpenSSL-Mailingliste diskutiert wurde, wurde der Fehler nicht erkannt.
Das ist unwahr, diskutiert wurde vielmehr folgendes:
When debbuging applications that make use of openssl using valgrind, it can show alot of warnings about doing a conditional jump based on an unitialised value. -- Kurt Roeckx
Der Debian-Maintainer Kurt Roeckx hat sich weder als solcher zu erkennen gegeben, noch erwähnt, daß seine Änderungen in das OpenSSL-Paket in Debian GNU/Linux 4.0 einfließen werden.
Alles nachzulesen hier:
http://marc.info/?t=114651088900003&r=1&w=2
In die Kritik gerät allerdings auch OpenSSL selbst. Deren Code versucht, die Entropie des Zufallsgenerators zu erhöhen, indem Zufallszahlen aus verschiedenen Quellen hinzugefügt werden. Eine dieser Quellen ist eine Bytefolge, die an einer Stelle lediglich auf »nicht initialisierten« Speicher verweist.
Das ebenfalls unwahr. Hier wiederholt Pro-Linux nur den Irrtum von Kurt Roeckx. OpenSSL verwendet nirgendwo uninitialisierten Speicher zur Initialisierung des Zufallsgenerators.
- Er gab sich nicht als Debian-Maintainer zu erkennen
- Er gab sich harmlos-naiv bezüglich der Auswirkungen des "Bugfixes", was im krassen Widerspruch zu seiner Funktion als Maintainer eines sicherheitskritischen Pakets steht. Würden sich bei Debian n00bs mit Security-Paketen beschäftigen, wäre dies automatisch ein K.O.-Kriterium für diese und alle abgeleiteten Distributionen.
Ich gehe davon aus, dass der Mann genau wußte, was er tat, als er Entropie aus einem RNG herausnahm. Ihm musste auch bewusst sein, dass alle Pakete, die auf OpenSSL zurückgreifen, davon betroffen sind.
Es scheint, als wollte er lediglich ein paar harmlose Antworten der OpenSSL-Entwickler provozieren, um seinen "Patch" zu legitimieren.
So abgesichert, wollte das dann keiner mehr hinterfragen, und er pflegte den Patch mit einem unauffälligen Kommentar ein.
Offenbar interessiert es niemanden, ob diese verheerende Änderung vielleicht absichtlich geschehen konnte. Die Story von wegen valgrind-Errors ist völlig unglaubwürdig.
Es wäre jedenfalls interessant zu wissen, wo dieser Herr noch überall seine Finger im Spiel hat. Wer weiß, vielleicht pflegt er ja noch ein paar sicherheitskritische Pakete, wo weitere Backdoors ihrer Entdeckung harren?
Und kanzelt mich bitte nicht mit "Verschwörungstheoretiker" ab. Die ganze Story stinkt gewaltig nach Manipulation.
http://www.debian.org/doc/developers-reference/
ch-developer-duties#s-upstream-coordination
"3.5 Coordination with upstream developers
A big part of your job as Debian maintainer will be to stay in contact with the upstream developers. Debian users will sometimes report bugs that are not specific to Debian to our bug tracking system. You have to forward these bug reports to the upstream developers so that they can be fixed in a future upstream release.
While it's not your job to fix non-Debian specific bugs, you may freely do so if you're able. When you make such fixes, be sure to pass them on to the upstream maintainers as well. Debian users and developers will sometimes submit patches to fix upstream bugs — you should evaluate and forward these patches upstream.
If you need to modify the upstream sources in order to build a policy compliant package, then you should propose a nice fix to the upstream developers which can be included there, so that you won't have to modify the sources of the next upstream version. Whatever changes you need, always try not to fork from the upstream sources."
Eindeutiger geht es wohl nicht:
"When you make such fixes, be sure to pass them on to the upstream maintainers as well."
Die strikte Befolgung dieser Guidelines hätte wohl den Debian-Openssl-Bug schon zu Beginn verhindert.