Zusammenfassung

  • Debian behob im Mai 2008 einen distributionsspezifischen Fehler im Zufallszahlengenerator seines OpenSSL-Pakets. Das Update schützte neue Erzeugung, änderte aber keinen seit September 2006 generierten SSH-, OpenVPN-, DNSSEC- oder X.509-Schlüssel, der bereits auf andere Systeme gelangt war.
  • Die tatsächliche Reparatur bestand aus getrennten Entscheidungen: Herkunft feststellen, erkennbare schwache Schlüssel sperren, Ersatz mit korrekter Entropie erzeugen, dessen Verteilung authentisieren, alte Berechtigungen löschen oder Zertifikate widerrufen und die Ablehnung bei jedem maßgeblichen Vertrauenden nachweisen.

Ein Paketupdate ohne Rückwirkung

Der 13. Mai 2008 teilte das Problem in zwei Zeiten. DSA-1571-1 meldete, dass der Zufallszahlengenerator des Debian-OpenSSL-Pakets vorhersehbar war. Nach dem Update würde der nächste erzeugte Schlüssel aus einem korrigierten Prozess stammen. Der am Vortag erzeugte Schlüssel blieb unverändert.

Ein schwacher Schlüssel sah nicht zwangsläufig beschädigt aus. Er ließ sich parsen, seine öffentliche Hälfte passte zur privaten, eine SSH-Signatur wurde verifiziert, ein X.509-Zertifikat konnte gültig signiert und noch nicht abgelaufen sein. Der Fehler lag in der unsichtbaren Entstehung: Das Geheimnis war aus einem viel zu kleinen Raum gewählt worden.

Deshalb verlangte Debian mehr als ein Upgrade. Sämtliches kryptografisches Material, das mit betroffenen Versionen ab 0.9.8c-1 erzeugt worden war, sollte neu erstellt werden. Für DSA galt eine zusätzliche Grenze: Selbst ein ursprünglich starker Schlüssel konnte durch einen vorhersehbaren Signatur-Nonce auf einem betroffenen System kompromittiert werden.

Ubuntu zog den Wirkungsbereich entlang des Schlüssels. Debian-basierte Systeme trugen den fehlerhaften Generator. Ein völlig anderes Betriebssystem konnte dennoch einen dort erzeugten schwachen Schlüssel importieren und akzeptieren. Softwareherkunft und Vertrauensbeziehung waren nicht dieselbe Landkarte.

Wie ein scheinbar großer Schlüsselraum schrumpfte

Debian-Bug #363516 begann im April 2006 mit Valgrind-Meldungen über das Lesen nicht initialisierten Speichers im OpenSSL-Zufallsgenerator. Die Diskussion behandelte Wege, diese Diagnose zu bereinigen. Der spätere Eintrag stellte klar, dass die tatsächlich kompilierte verwundbare Änderung erst mit 0.9.8c-1 wirksam wurde, als die modifizierte Datei an die verwendete Build-Stelle gelangte.

Debians SSLkeys-Dokumentation beschreibt das praktische Ergebnis. Der defekte Generator wurde im Wesentlichen nur durch die Prozess-ID gespeist. Mit 32.767 möglichen Folgen in jeder von drei Architekturklassen ergab das Modell 98.301 Folgen. Für verbreitete Schlüsseltypen und Längen konnten Kandidaten vorberechnet und einer beobachteten öffentlichen Hälfte zugeordnet werden.

Die Zahl ist weder ein Zähler aller schwachen Schlüssel noch aller Angriffe. Anwendungen nutzten die Bibliothek unterschiedlich; Algorithmen, Längen und Architekturen variierten; Blacklists waren unvollständig. Sie zeigt jedoch den entscheidenden Bruch. Ein öffentlicher Schlüssel darf offenliegen, weil die private Hälfte praktisch unerreichbar sein soll. Hier half die öffentliche Hälfte, einen Eintrag aus einem berechenbaren Katalog zu finden.

Das Format blieb gültig. Die tatsächliche Knappheit des Geheimnisses war verloren.

Debian schaltete Vertrauen gesondert ab

Kurz nach der Bekanntgabe deaktivierte das Debian-Projekt die SSH-Public-Key-Anmeldung auf seinen eigenen Systemen. Schlüsselgestützte Transfers und Build-Abläufe konnten erst weiterlaufen, wenn ihre Zugangsdaten geprüft oder ersetzt waren.

Dieser Schritt beweist die Trennung. Hätte das Bibliotheksupdate alte Schlüssel widerrufen, wäre die lokale Sperre überflüssig gewesen. Debian reparierte den Ursprung und betätigte danach den eigenen Ablehnungspunkt.

DSA-1576-1 brachte openssh-blacklist und ssh-vulnkey. Bekannte schwache Benutzerschlüssel konnten soweit erkennbar zurückgewiesen werden. Hostschlüssel ließen sich mit Zustimmung neu erzeugen. Der Austausch lief jedoch in zwei Richtungen.

Ein neuer Hostschlüssel löste auf Clients die Warnung über eine geänderte entfernte Identität aus. Eine legitime Reparatur sah an dieser Stelle genauso aus wie ein Man-in-the-Middle-Angriff. Deshalb musste der neue Fingerabdruck über einen vertrauenswürdigen zweiten Kanal bestätigt werden. Die Warnung pauschal abzuschalten hätte die lokale Vetomöglichkeit zerstört.

Ein neuer Benutzerschlüssel musste dagegen an jeden Server verteilt und der alte Eintrag aus jedem authorized_keys entfernt werden. Wer nur den Ersatz hinzufügte, besaß zwei Zugänge; der erratbare blieb aktiv.

Paket, Blacklist, Ersatzschlüssel, Fingerabdruckkanal und entfernte Berechtigungszeile hatten verschiedene Eigentümer. Kein einzelner Schritt konnte für die gesamte Kette sprechen.

Eine Blacklist mit ehrlicher Reichweite

Der kleine Kandidatenraum ermöglichte ein ungewöhnliches Gegenmittel. Bekannte schwache öffentliche Schlüssel konnten aufgelistet werden; der Empfänger verglich eine angebotene Zugangsdaten lokal und verweigerte sie. Veröffentlichte Evidenz wurde ausführbarer Widerspruch.

Doch eine Liste sperrte keinen Schlüssel aus der Ferne. Sie wirkte nur, wenn passendes Paket, Parser, Schlüsseltyp und Länge vorhanden waren und die Anwendung die Ablehnung ausführte. Debian sprach bewusst von Ablehnung „wo möglich“. Unknown (no blacklist information) bei Ubuntu bedeutete: keine Aussage im vorhandenen Korpus. Es bedeutete nicht sicher.

DSA-1576-2 korrigierte einen frühen Parserfehler. authorized_keys-Zeilen mit vorangestellten Optionen, etwa erzwungenen Befehlen, konnten übersehen werden. Ein Server akzeptierte den Schlüssel weiter, während der Bericht ihn ausließ. Spätere Ubuntu-Updates erweiterten Zertifikate, Signieranfragen, Moduli und RSA-Längen.

Die Blacklist blieb wertvoll. Sie schützte auch einen nie verwundbaren Host vor importierten bekannten Schlüsseln und vor späterem Wiedereintrag. Ihre Aussage musste nur proportional zur Evidenz bleiben: Treffer heißt ablehnen; kein Treffer heißt nicht automatisch sicher.

Für jedes Protokoll ein anderer Austritt

CERT nannte SSH, OpenVPN, DNSSEC und X.509. Die gemeinsame Ursache erzeugte keinen gemeinsamen Widerruf.

Beim SSH-Benutzerschlüssel lag die Befugnis in entfernten Autorisierungsdateien. Abschluss bedeutete, dass der alte private Schlüssel an allen wesentlichen Servern scheiterte. Beim SSH-Hostschlüssel lag Vertrauen auf den Clients und in der authentisierten Mitteilung des neuen Fingerabdrucks.

Ein geteilter OpenVPN-Schlüssel musste auf sämtlichen Peers koordiniert ersetzt werden. Zertifikatsbasierte VPNs brauchten zusätzlich neue Ausstellung und Ablehnung der alten Berechtigung. USN-612-3 verlangte, auch für andere Systeme erzeugtes Material dort aufzuspüren.

Bei X.509 machte eine Neuausstellung das alte Zertifikat nicht unsichtbar. Der Aussteller konnte Widerruf veröffentlichen, der Dienst musste die neue Kette ausrollen, der Client frischen Status verarbeiten. RFC 5280 definiert Zertifikat- und CRL-Prüfung; es garantiert nicht, dass jede installierte Anwendung sofort den neuen Zustand abfragt.

DNSSEC verlangte protokollspezifischen Rollover über signierte Delegationen und Caches. Automationsschlüssel konnten in Images, Sicherungen, Geräten und Partnernetzen fortleben. Das Löschen am Erzeuger änderte deren Annahmeregel nicht.

Die Reparatureinheit war somit die Zugangsdaten-Linie: Erzeugung, Kopien, Zertifikate, Berechtigungen und alle Orte, die weiterhin „ja“ sagten.

Korrekte Mathematik, verlorene Berechtigung

SSH prüft den Besitz des Geheimnisses zur angebotenen öffentlichen Hälfte. Es prüft nicht, ob nur der legitim Berechtigte dieses Geheimnis kennt. Ein Angreifer mit vorberechnetem privaten Schlüssel konnte eine mathematisch korrekte Authentisierung liefern.

Die Validität überlebte die legitime Grundlage.

Heng Lus veröffentlichte Running-Code-Perspektive kann diesen Mechanismus erklären, ist aber kein Beleg für die Debian-Chronologie. Advisory, Patch, Blacklist und Zertifikatsstatus sind Information und Regel. Wirksam wird die Ablehnung dort, wo SSH-Server, VPN-Peer oder PKI-Client sie ausführt. Debian beherrschte seine Pakete und eigenen Systeme, nicht jede entfernte Autorisierungsdatei.

Umgekehrt blieb ein nie verwundbares System Teil des Vorfalls, wenn es einen importierten schwachen Schlüssel akzeptierte. Praktische Kontrolle saß beim jeweiligen Vertrauenden. Dieses lokale Veto war Schutz und Verantwortung zugleich.

Vier Register für einen belastbaren Abschluss

Das Erzeugungsregister verknüpft Fingerabdruck mit Datum, Paket, Bibliothek, Anwendung, Architektur, Algorithmus und Länge. Das Verteilungsregister erfasst private Kopien, Zertifikate, Server, authorized_keys, known_hosts, Peers, Images, Backups und Partner.

Das Ersatzregister verbindet alten und neuen Fingerabdruck, Authentisierungskanal, Verantwortlichen und Termin. Das Ablehnungsregister beweist, dass der alte Schlüssel scheitert, alte Zertifikate bei getesteten Clients abgewiesen werden und Ausnahmen befristet sind.

Patchquote misst den Beginn. Übrig gebliebene Berechtigung misst das Ende.

Evidenzgrenzen

Die amtlichen Quellen liefern keinen vollständigen Zähler schwacher Schlüssel oder erfolgreicher Angriffe. 98.301 Folgen sind ein begrenztes Modell. Unknown ist weder Sicherheits- noch Schwächebeweis. Backups und falsche Uhren können Dateizeiten verändern. GnuPG und GnuTLS nutzten andere Quellen. Automatische Hostschlüsselerneuerung hing von Paket und Administrator ab. Neuausstellung beweist keine universelle Widerrufsprüfung.

Gesichert ist: Der korrigierte Generator schützte die Zukunft; alte Zugangsdaten verloren ihre Macht erst an jedem einzelnen Annahmepunkt.

Quellen