Abo
  • IT-Karriere:

Kryptographie: Der Debian-Bug im OpenSSL-Zufallszahlengenerator

Einer der schwerwiegendsten Fehler in der Geschichte der Kryptographie beschäftigte vor zehn Jahren Nutzer der Debian-Distribution. Wenn man danach sucht, findet man noch heute vereinzelt verwundbare Schlüssel.

Artikel von Hanno Böck veröffentlicht am
An einigen Stellen findet man immer noch alte kryptographische Schlüssel, die sich dank eines zehn Jahre alten Debian-Bugs knacken lassen.
An einigen Stellen findet man immer noch alte kryptographische Schlüssel, die sich dank eines zehn Jahre alten Debian-Bugs knacken lassen. (Bild: Bubo/Wikimedia Commons/CC-BY-SA 3.0)

Es war ein GAU in Sachen Verschlüsselung: 2008 entdeckte der Debian-Entwickler Luciano Bello einen Bug, der für einen Zeitraum von zwei Jahren dazu führte, dass der Zufallszahlengenerator von OpenSSL praktisch unbrauchbar wurde. Bis heute finden sich vereinzelt verwundbare private Schlüssel im praktischen Einsatz.

Stellenmarkt
  1. HRG Hotels GmbH, Berlin
  2. DI Deutsche Immobilien Gruppe (DI-Gruppe), Düren

Grund für den Fehler war ein Patch, mit dem eigentlich ein Problem behoben werden sollte. Der originale OpenSSL-Code nutzte für den Zufallszahlengenerator uninitialisierten Speicher. Die Debian-Entwickler störten sich daran, dass das Debugging-Tool Valgrind hierzu eine Warnung ausgab und wollten dieses Problem ausschalten.

Zufallszahlengenerator hatte nur noch 32.768 Möglichkeiten

An sich sprach auch nichts dagegen, doch der Patch enthielt einen gravierenden Fehler. Dieser führte dazu, dass fortan nur noch wenige Daten in den internen Status des Zufallszahlengenerators gelangten. Die einzige Quelle von zufälligen Daten war fortan die Prozess-ID der jeweils laufenden Softwareinstanz. Unter Linux kann die Prozess-ID Werte zwischen 1 und 32.768 annehmen - es gibt also nur eine relativ begrenzte Zahl an Möglichkeiten.

Die größten Auswirkungen hatte der Fehler auf die Erzeugung von kryptographischen Schlüsseln. Er unterschied sich je nach Architektur, Version und Konfiguration des jeweiligen Systems, doch insgesamt gab es für jede Schlüsselgröße nun nur noch einige Hunderttausend mögliche Varianten. Die Folge: Wer mit OpenSSL einen privaten Schlüssel für ein Serverzertifikat erzeugte, musste damit rechnen, dass ein Angreifer schlicht alle möglichen Schlüsselvarianten erzeugte und somit ebenso in den Besitz des privaten Schlüssels kam.

Nicht nur OpenSSL war davon betroffen, auch andere kryptographische Software, die OpenSSL nutzt, erzeugte knackbare Schlüssel, darunter OpenSSH und OpenVPN.

Die Schlüsselerzeugung war dabei nur das offensichtlichste Problem, auch Software, die kryptographische Verbindungen herstellt - etwa ein Webserver -, konnte durch den Bug angegriffen werden. Allerdings gestalteten sich solche Angriffe etwas komplizierter, da der genaue Status des Zufallszahlengenerators nur schwer vorhersehbar ist, wie eine damals veröffentlichte wissenschaftliche Abhandlung erläutert.

Immer noch verwundbare Keys im Einsatz

Obwohl das Ganze schon zehn Jahre her ist, sind vereinzelt immer noch verwundbare private Schlüssel zu finden. 2015 fand der Softwareentwickler Ben Cox bei Github zahlreiche öffentliche SSH-Schlüssel von Entwicklern mit dem alten Debian-Bug. Damit hätte man einige prominente Code-Repositories manipulieren können, etwa das von Python.

Bei TLS-Zertifikaten für Webseiten sollte es theoretisch unmöglich sein, solche verwundbaren Schlüssel zu verwenden. Alle Zertifikate, die damals gültig waren, sind längst abgelaufen. Die Baseline Requirements, ein Regelwerk, auf das sich Zertifizierungsstellen und Browserhersteller geeinigt haben, sieht vor, dass bei der Zertifikatsausstellung geprüft wird, ob ein bekannter kompromittierter Schlüssel verwendet wird. Der Debian-OpenSSL-Bug wird dabei explizit als Beispiel erwähnt.

Trotzdem tauchen immer noch Zertifikate auf, die von dem Bug betroffen sind. Im vergangenen Jahr gelang es dem Autor dieses Artikels, ein Testzertifikat mit verwundbarem Schlüssel bei Let's Encrypt zu erstellen. Let's Encrypt hat inzwischen einen Check eingebaut, der eine solche Zertifikatsausstellung verhindert.

Auch fanden sich in den Daten der Certificate-Transparency-Logs zwei von der Zertifizierungsstelle Certum ausgestellte Zertifikate, deren Schlüssel mit einem verwundbaren Debian-System erzeugt wurden, ebenso Zertifikate der inzwischen nicht mehr von Browsern akzeptierten Zertifizierungsstellen Startcom und Wosign. Bei der Recherche zu diesem Artikel fand sich zudem ein weiteres Zertifikat, ausgestellt von der Zertifizierungsstelle Quo Vadis.

Der Debian-OpenSSL-Bug ist wohl eine der gravierendsten Sicherheitslücken in der Geschichte der Kryptographie. Entscheidend für die Langlebigkeit ist vor allem, dass nicht nur die Verschlüsselung, sondern die erzeugten privaten Schlüssel von der Lücke betroffen waren. Sucht man nach vergleichbaren Bugs, dann fällt einem am ehesten die ROCA-Sicherheitslücke in Infineon-Chips ein. Die führte im vergangenen Jahr dazu, dass unzählige Personalausweise, Krypto-Chipkarten und Produkte wie Yubikeys knackbare Schlüssel erzeugten.



Anzeige
Top-Angebote
  1. (u. a. Sandisk 512-GB-SSD für 55,00€, WD Elements Exclusive Edition 2 TB für 59,00€ und Abend...
  2. 31,99€
  3. 139,00€ (Bestpreis!)
  4. (aktuell u. a. Speedlink Velator Gaming-Tastatur für 9,99€, Deepcool New Ark Gehäuse für 249...

/mecki78 28. Mai 2018

Wenn OpenSSL in der Lage ist in kurzer Zeit viele gute Zufallswerte zu erzeugen, warum...

My1 28. Mai 2018

4 millionen is auch nix in dem bereich.


Folgen Sie uns
       


Asus Zephyrus G GA502 - Test

Sparsamer Sprinter mit dunklem Display: das Zephyrus G GA502 im Test.

Asus Zephyrus G GA502 - Test Video aufrufen
Verkehrssicherheit: Die Lehren aus dem tödlichen SUV-Unfall
Verkehrssicherheit
Die Lehren aus dem tödlichen SUV-Unfall

Soll man tonnenschwere SUV aus den Innenstädten verbannen? Oder sollten technische Systeme schärfer in die Fahrzeugsteuerung eingreifen? Nach einem Unfall mit vier Toten in Berlin mangelt es nicht an radikalen Vorschlägen.
Eine Analyse von Friedhelm Greis

  1. Torc Robotics Daimler-Tochter testet selbstfahrende Lkw
  2. Edag Citybot Wandelbares Auto mit Rucksackmodulen gegen Verkehrsprobleme
  3. Tusimple UPS testet automatisiert fahrende Lkw

Ryzen 7 3800X im Test: Der schluckt zu viel
Ryzen 7 3800X im Test
"Der schluckt zu viel"

Minimal mehr Takt, vor allem aber ein höheres Power-Budget für gestiegene Frequenzen unter Last: Das war unsere Vorstellung vor dem Test des Ryzen 7 3800X. Doch die Achtkern-CPU überrascht negativ, weil AMD es beim günstigeren 3700X bereits ziemlich gut meinte.
Ein Test von Marc Sauter

  1. Agesa 1003abba Microcode-Update taktet Ryzen 3000 um 50 MHz höher
  2. Agesa 1003abb Viele ältere Platinen erhalten aktuelles UEFI für Ryzen 3000
  3. Ryzen 5 3400G und Ryzen 3 3200G im Test Picasso passt

TVs, Konsolen und HDMI 2.1: Wann wir mit 8K rechnen können
TVs, Konsolen und HDMI 2.1
Wann wir mit 8K rechnen können

Ifa 2019 Die Ifa 2019 ist bezüglich 8K nüchtern. Wird die hohe Auflösung wie 4K fast eine Dekade lang eine Nische bleiben? Oder bringen kommende Spielekonsolen und Anschlussstandards die Auflösung schneller als gedacht?
Eine Analyse von Oliver Nickel

  1. Kameras und Fernseher Ein 120-Zoll-TV mit 8K reicht Sharp nicht
  2. Sony ZG9 Erste 8K-Fernseher werden bald verkauft
  3. 8K Sharp schließt sich dem Micro-Four-Thirds-System an

    •  /