Konsequenzen des OpenSSL-Debakels

Der Fehler im OpenSSL-Paket von Debian entfacht die Diskussion über Zuständigkeiten für Patches und Bugfixes. Unterdessen kommen Details zur Schwachstelle und erste Exploits für SSH-Schlüssel ans Licht.

In Pocket speichern vorlesen Druckansicht 411 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Christiane Rütten

Rund um die selbstverschuldete Schwachstelle im OpenSSL-Paket von Debian ist eine rege Diskussion um die Ursachen und Konsequenzen entbrannt. OpenSSL-Entwickler und Mitgründer der Apache Foundation, Ben Laurie beschwerte sich zunächst massiv in einem Blog-Beitrag mit dem Titel "Vendors Are Bad For Security". Paket-Maintainer sollten nicht selbst an Quellcode herumbasteln, von dem sie nichts verstünden. Stattdessen sollten sie sich stets an die Entwickler wenden, die die Patches begutachten und einpflegen könnten, also ihre Bugfixes "upstream" Richtung Quelle kommunizieren. Dann wäre es niemals zu dem Problem gekommen, so Laurie.

Doch die Verantwortlichkeit ist in diesem Fall nicht ausschließlich bei den Maintainern des Debian-OpenSSL-Paketes zu suchen. Ihnen war offenbar durchaus bewusst, dass die Modifikation für schlechtere Zufallszahlen sorgen würden, weshalb sie auf der OpenSSL-Entwicklerliste eine Unbedenklichkeitsbestätigung einholten, bevor sie die fatale Änderung in ihr Paket einpflegten. Einspruch kam auch im Nachhinein nicht. Laurie rudert in einem weiteren Blog-Beitrag ein Stück weit zurück und räumt unter anderem Kommunikationsprobleme auf Seiten des OpenSSL-Teams ein.

Es ist durchaus üblich, dass Linux-Distributoren selbst in den Quellcode eingreifen, um Patches und Sicherheits-Updates in ihre Pakete einzupflegen. Insbesondere bei kleineren Programmierprojekten kann es lange dauern, bis Änderungen und Bugfixes in die Original-Quellen einfließen. Da die Distributoren in der Regel aus Stabilitätsgründen auch nicht die brandaktuellen Versionen verwenden, müssen sie die Patches ohnehin meist auf ihre älteren Versionen zurückportieren. Dieses Problem bestätigten auch Martin Schulze und Florian Weimer vom Debian-Projekt gegenüber heise Security. Sie wiesen aber darauf hin, dass Debian-Maintainer gemäß den Entwickler-Richtlinien möglichst eng mit den Upstream-Entwicklern zusammenarbeiten sollen, damit die Änderungen auch in die Original-Quellen einfließen können.

Auslöser für die Änderungen am OpenSSL-Paket waren Fehlermeldungen des Qualitätssicherungs-Tools Valgrind, das potenzielle Speicherlecks in der Verschlüsselungssoftware meldete. Die Änderung der Debian-Maintainer hatte zum Zweck, die ungewöhnlichen Zugriffe auf unbelegte Speicherbereiche abzuschalten, die in der Regel ein Hinweis auf Programmierfehler sind. Doch anstatt die konkreten Funktionsaufrufe für den unbelegten Speicherbereich zu entfernen, nahm der "Bugfix" laut Laurie der untergeordneten Funktion ssleay_rand_add() jede Möglichkeit, Daten in den Entropie-Pool zu übernehmen. Unbelegter Arbeitsspeicher ist dafür allerdings nur eine von mehreren möglichen Quellen.

Die Folge war, dass das Debian-OpenSSL nur noch die unter Linux 15 Bit lange Linux Prozess-ID für Zufallszahlen heranzog. Dies macht damit erstellte SSH- und SSL/TLS-Schlüssel mit einem einfachen Brute-Force-Angriff erratbar. Inzwischen kursieren Test-Tools und Exploits, darunter auch im Metasploit-Framework, für die schwachen SSH-Schlüssel mit einer Länge bis zu 4096 Bit. Diese basieren auf Schlüssellisten, die sich ergeben, wenn man die Schlüsselberechnung für jede der rund 32.000 möglichen Prozess-IDs durchführt. Die Knackprogramme für SSH-Key-Logins sind nur wirksam, wenn Anwender auf einem SSH-Host schwache SSH-Schlüssel für passwortlose Log-ins hinterlegt haben.

Bei den X.509-Zertifikaten für SSL und TLS ist die Situation hingegen noch unklar. Im Debian-Wiki ist zwar eine Methode beschrieben, wie sich X.509-Schlüssel im PEM-Format für die Tests in SSH-Schlüssel umwandeln lassen. Doch Wiki-Schreiber berichten, dass die auf SSH ausgelegten Test-Programme auch dann nicht anschlagen, wenn die Zertifikate mit einer verwundbaren OpenSSL-Version erstellt wurden. Im Zweifel sollten Anwender alle seit September 2006 erzeugten SSL- und SSH-Schlüssel neu generieren und damit ausgestellte Zertifikate zurückrufen. Insbesondere auf betroffene Zertifizierungsstellen dürfte viel Arbeit zukommen.

Siehe dazu auch:

(cr)