Stefans Home

Debian (und Debian-Derivate wie Ubuntu) hat ein akutes Problem mit OpenSSL-Schlüsseln, die nach dem 17.9.2006(!) erzeugt wurden: Durch einen Debian-spezifischen Patch sind die verwendeten Zufallszahlen so schwach, daß die Schlüssel leicht gebrochen werden können und somit die Verschüsselung von OpenSSH, https und vielen weiteren mehr oder minder hinfällig ist. Seit gestern existiert ein Programm zum automatischen Brechen solcher Schlüssel - es ist also höchste Zeit, sein Schlüsselmaterial zu aktualisieren und auf mögliche Einbrüche zu prüfen! Die Geschichte hinter dem Bug liest sich übrigens mehr als gruselig:

Ein Debian-Entwickler hat nach diesem Bericht OpenSSL mit valgrind untersucht. Valgrind ist ein Tool, um Speicherlecks und diverse Programmierfehler aufzuspüren. Valgrind entdeckte tatsächlich ein potentielles Problem: An einer Stelle wurde auf nicht initalisierten Speicher zugegriffen - also Speicher, der vom Programm angefordert, aber noch nicht sinnvoll belegt wurde (ein typischer Programmierfehler ist es, versehentlich mit dem potentiellen Datenmüll zu arbeiten). Daraufhin entfernte der Debian-Entwlickler den Aufruf, der zu dem Fehler führte. Dummerweise war dies ein Teil der Routine, welche Zufallszahlen für die Generierung von Schlüsseln besorgt - OpenSSL nutzt offensichtlich solchen Speichermüll als Entropiequelle.
Autsch - wie kann man nur in einem sicherheitskritischen Programm so unkritisch herumfuhrwerken? Ich stelle mir gerade den zugehörigen Logeintrag vor: "Aufruf der Routine entfernt, diese lieferte keine sinnvollen Daten, nur zufällige Bits"...

Die Analyse dieser "Verbesserung" zeigt, daß die erzeugten Schlüssel nun einzig und allein von der Prozeß-ID des Programmlaufs abhiengen - damit schrumpfte der Raum der Zufallszahlen auf 32768 verschiedene Werte. Daß man diese trivial durchprobieren kann, ist wohl offensichtlich.

Ein geknackter Schlüssel bedeutet, daß sich der betroffene Datenverkehr abhören oder via man-in-the-middle manipulieren läßt. Damit wird de facto ssh zu telnet und https zu http, jede solche Verbindung kann potentiell abgehört werden. ssh-Keys zur Authentisierung via Schlüssel sind ebefalls betroffen, so kann eine solche Authentisierung mit (im Schnitt) ca. 16000 Login-Versuchen geknackt werden. In kritischen Umgebungen müssen auch ssh-Keys, die zwar mit einer nicht kompromittierten Version generiert wurden, aber deren Secret Key auf einem System mit schwachem ssh-Host-Key lag, als kompromittiert betrachtet werden.

Unter dem Aspekt, daß man so nur wenige ssh-Keys für einen Account durchprobieren muß, erscheinen auch die ssh-Scans nach root-Accounts, die ich seit dem 7. Mai in meinen Logs finde, in einem ganz anderen Licht. In diesem Blogeintrag habe ich Links auf das svn-Repository von Debian gefunden: dies war der fatale Patch und dies ist der Fix. Der Fix wurde also 5 Tage vor dem offiziellen Advisory, also am 8. Mai eingespielt! Dies läßt die Debianer in einem doppelt schlechten Licht erscheinen: Zum einen wurde ein wirklich wichtiger Patch nicht zeitnah kommuniziert, zum andern drängt sich die Vermutung auf, daß Leute, welche von dem Problem Kenntnis hatten (was insbesondere Debianer gewesen sein dürften), ganz schnell ans Scannen gemacht haben.

Debian liefert im aktualisierten Paket ein Tool namens ssh-vulnkey mit, mit dem geprüft werden kann, ob ein Schlüssel mit einer defekten openssl-Version erzeugt wurde. Man kann damit aber auch überprüfen, welche Webseiten schwache Schlüssel benutzen - so zum Beispiel whitehouse.gov... ich habe die Befürchtung, daß die Bezeichnung "security fuckup des Jahres" keine allzu große Untertreibung sein dürfte.