Wie ich über die Debian-Schwachstelle mit schwachen Schlüsseln stolperte

Die Geschichte, wie ich auf die Debian-Schwachstelle mit schwachen Schlüsseln gestoßen bin

• Im März 2008 arbeitete der Autor bei Engine Yard (EY)
• Damals half EY GitHub, indem es kostenlose Infrastruktur bereitstellte
• Als GitHub wuchs, trat das Problem auf, dass SSH-Logins langsam wurden
• GitHub verwaltete SSH-Schlüssel mit der Standardmethode über die Datei ~/.ssh/authorized_keys
• SSH öffnet diese Datei, wenn sich ein Benutzer verbindet, und durchsucht sie linear nach einem Schlüssel, der mit dem vom Benutzer präsentierten Schlüssel übereinstimmt
• Normalerweise ist das kein Problem, weil nur einige wenige Schlüssel vorhanden sind, aber bei vielen Nutzern wie bei GitHub wird es langsam

Entscheidung, statt der authorized_keys-Datei eine MySQL-Datenbank zu verwenden

• Nach Prüfung mehrerer Alternativen entschied man sich, OpenSSH zu patchen, damit die Schlüsselsuche über eine MySQL-Datenbank erfolgt
• Das war eine sorgfältig abgewogene Entscheidung, und es wurde viel Aufwand betrieben, um die Sicherheit nicht zu beeinträchtigen
• Anfang April 2008 wurde die Änderung eingeführt und das Problem der langsamen SSH-Logins gelöst

Etwas Seltsames passiert

• Einen Monat später, Anfang Mai, trat ein Problem auf, bei dem einige Benutzer per SSH auf die Repositories anderer Benutzer zugreifen konnten
• Die Untersuchung ergab, dass verschiedene Benutzer Schlüssel mit demselben Fingerabdruck verwendeten
• Das dürfte nicht passieren, es sei denn, sie teilen sich denselben Schlüssel
• Die Benutzer sagten, sie kennten einander nicht und wüssten nicht, wie ihre Schlüssel kompromittiert worden sein könnten
• Dasselbe Problem wurde auch bei anderen Benutzerpaaren gefunden
• Die einzige Gemeinsamkeit war, dass alle Debian- oder Ubuntu-Systeme verwendeten

Die Ursache wird aufgeklärt

• Am 13. Mai 2008 wurde mit der Veröffentlichung von DSA-1571-1 alles klar
• Ein Debian-Maintainer hatte beim Aufräumen des OpenSSL-Codes zur Zufallszahlengenerierung versehentlich die Zahl möglicher Schlüssel auf etwa 32.000 reduziert
• Viele Menschen meldeten sich bei GitHub an und erzeugten nach Best Practice neue Schlüssel, was zu Kollisionen führte
• Danach befasste sich der Autor noch stärker mit diesem Problem, etwa indem er bekannte schwache Schlüssel nutzte, um betroffene Zertifizierungsstellen zu finden

Meinung von GN⁺

• Um eine so wichtige Schwachstelle zu finden, braucht man Zeit und Energie, um zu denken „Irgendetwas ist seltsam“ und hartnäckig weiter zu untersuchen. Meistens fehlt dieser Spielraum, daher braucht es oft auch Glück.
• Die meisten Menschen sind im Alltag zu beschäftigt, um bis zur eigentlichen Grundursache eines Problems vorzudringen. Dass unsere Branche sich diesen Spielraum zurückholt, ist eine wichtige Aufgabe.
• OpenSSL ist eine der am weitesten verbreiteten Kryptografie-Bibliotheken, daher ist die Auswirkung einer solchen Schwachstelle sehr groß. Hier zeigt sich zugleich die Stärke und die Schwäche von Open Source.
• Um solche Schwachstellen zu verhindern, müssen Code Reviews und Sicherheitsaudits verstärkt und Änderungen an kritischen Teilen noch sorgfältiger geprüft werden. Eine perfekte Methode gibt es aber nicht.
• Trotzdem hat Open Source den Vorteil, dass Fachleute den Code direkt prüfen und Probleme finden können. Bei geschlossenen Programmen ist selbst das nicht möglich.

[GN⁺]

Hacker-News-Kommentar

• Luciano Bello entdeckte die Schwachstelle CVE-2008-0166 zufällig; den damaligen IRC-Logs zufolge waren viele Primzahlen nötig, und es ergab sich nicht jedes Mal dieselbe Zahl
• Insgesamt hatte die Branche wohl Glück, weil es jemanden mit den Fähigkeiten sowie der Zeit und Energie gab, rechtzeitig einen großen Unterschied zu machen. Das ist ein anschauliches Beispiel für die Statistik hinter „many eyes“ und „sunlight is the best disinfectant“. Selbst wenn die Wahrscheinlichkeit noch so gering ist, dass jemand zufällig einen Bug entdeckt, wird er entdeckt, weil Menschen dazu in der Lage sind. Bei proprietärem/geschlossenem Code ist diese Wahrscheinlichkeit dagegen null
• Die Änderung, die diese Schwachstelle verursachte, wurde nicht überhastet vorgenommen. Ein Maintainer sprach das Problem auf der OpenSSL-Mailingliste an, bat um Feedback und schlug eine Lösung vor; er erhielt auch etwas Rückmeldung, einschließlich von Upstream. Das Ergebnis war eine schreckliche Schwachstelle, aber es wirkt wie ein extrem unglücklicher Fall, in dem niemand das Problem bemerkte
• GitHub kam zu dem Schluss, dass es die beste Option sei, OpenSSH so zu patchen, dass Schlüssel, die per Fingerabdruck indiziert in einer MySQL-Datenbank liegen, abgefragt werden. Offenbar entschied man sich statt für SQLite für MySQL, weil dies genau die Art von Fall war, in der MySQL glänzen konnte, während man den Zugriff auf ~/.ssh/authorized_keys beschleunigen wollte
• Das bringt einen dazu, über die Möglichkeit nachzudenken, dass so etwas in der Seed-Generierungsfunktion populärer Bitcoin-Hardware-Wallets passiert, und welche Folgen das hätte
• Auch die Erkennung von RSA-Schlüsseln mit gemeinsamen p- oder q-Faktoren mittels GCD war eine interessante Episode
• Man sieht, dass langsame SSH-Login-Zeiten aus den verschiedensten Gründen ein Hinweis sein können, dem nachzugehen sich lohnt
• OpenSSL RNG wurde mit nicht initialisiertem Stack-Speicher und der PID geseedet; selbst ohne den Debian-Patch wirkte schon das Seeding nur mit der PID an sich ziemlich riskant
• Ich frage mich, ob GitHub immer noch das gepatchte OpenSSH einsetzt
• Der Satz, dass Ezra Zygmuntowicz GitHub dem Autor vorgestellt und ihm Zeit gegeben habe, sich gemeinsam mit dem GitHub-Team in das Problem zu vertiefen, ist amüsant. Vielleicht auch, weil es so klingt, als hätte das GitHub-Team selbst ein großes Problem
• Ich frage mich, wie viel länger es unentdeckt geblieben wäre, wenn Luciano es nicht gefunden hätte. Vermutlich hätten es nur wenige Orte wie GitHub oder große Cloud-Anbieter, die Tausende von Schlüsseln ihrer Nutzer speichern, zufällig entdeckt