Dipl.-Inform. Carsten Eilers

Adam Gowdiak von Security Explorations hat Details (PDF) zur Schwachstelle, die Oracle für ein "erlaubtes Verhalten" ("allowed behavior") hält, veröffentlicht. Sie erinnern sich vielleicht: Nachdem Oracle abstritt, dass es sich um eine Schwachstelle handelt, hat Adam Gowdiak sich das Ganze noch mal genauer angesehen und dabei fünf weitere Schwachstellen gefunden. Und was die nun dokumentierte Schwachstelle betrifft: Wenn das ein erlaubtes Verhalten ist, sollte man es Java schleunigst verbieten. Denn das sieht doch sehr nach einer Schwachstelle aus. Die kann zwar nur zusammen mit einer weiteren Schwachstelle ausgenutzt werden, aber davon enthält Java ja bekanntlich mehr als genug. Und letztendlich: Wozu gibt es einen Security Manager, wenn er nicht konsequent eingesetzt wird? Das erinnert doch sehr an ein Gelände mit Wachen vor dem Tor, aber Lücken im Zaun außen rum. Dumme Angreifer melden sich bei der Wache, schlaue machen einen großen Bogen ums Tor, schlüpfen durch eine Lücke und kommen ungestört rein.

Während Oracle und Adam Gowdiak darüber streiten, ob es sich um einen Programmierfehler oder ein erwünschtes Verhalten handelt, ist die Antwort im folgenden Fall eindeutig: Ein handelt sich um einen Programmierfehler, und der hat drastische Folgen.

Geschichte wiederholt sich...

Ein Programmierfehler im Zufallszahlengenerator von NetBSD führt zur Erzeugung von zu schwachen kryptographischen Schlüsseln. Ursache ist laut Advisory eine falsch gesetzte Klammer. Die führt dazu, dass für die Erzeugung der Zufallszahlen zu wenige zufällige Eingangswerte (die sog. Entropie) verwendet werden. Das ist vor allem beim Systemstart der Fall, was dazu führt, dass auf 32-Bit-Systemen unter Umständen Schlüssel erzeugt werden, die nur 32 Bit Entropie enthalten, was zu 2³² und damit rund 4,3 Milliarden möglichen Schlüsseln führt. Und die kann man notfalls im Rahmen eines Brute-Force-Angriffs durchprobieren. Betroffen sind insbesondere SSH-Schlüssel, da die normalerweise beim Systemstart erzeugt werden. Mit NetBSD 6.0 oder NetBSD-Current erzeugte Schlüssel sollten daher ausgetauscht werden.

Falls Ihnen das jetzt bekannt vor kommt: Ja, so eine ähnliche Situation hatten wir schon mal. 2008 führte ein Fehler im OpenSSL-Paket von Debian dazu, dass vorhersagbare Schlüssel erzeugt wurden. Damals waren insbesondere die durch OpenSSL erzeugten OpenSSH-Schlüssel betroffen, was zu vermehrten Brute-Force-Angriffen auf SSH-Server führte. Aufgrund der großen Verbreitung von Debian und des langen Zeitraums, in dem vorhersagbare Schlüssel erzeugt wurden (der Fehler wurde am 17. September 2006 eingeführt und erst am 13. Mai 2008 behoben) waren damals sehr viele Server betroffen. Außer OpenSSH-Schlüsseln waren auch OpenVPN, DNSSEC und X.509 Zertifikate (z.B. für S/MIME, IPSec und SSL/TLS) gefährdet.

Aufgrund der geringeren Verbreitung von NetBSD dürften die Folgen diesmal im Rahmen bleiben, fatal ist der Fehler aber trotzdem. Immerhin gelten die BSD-Varianten ja als sichere Systeme. Dieser Ruf dürfte im Fall von NetBSD jetzt etwas angekratzt sein. Aber kratzt das irgend wen?

Wie heißt es doch so schön: Wer aus der Geschichte nicht lernt, läuft Gefahr, sie zu wiederholen? Ich hätte da eine Lektion für alle Entwickler, die sich mit Kryptographie beschäftigen: Prüfen Sie ihren Code doppelt und dreifach, schon kleine Fehler können gravierende Folgen haben. In Fall von NetBSD hat übrigens der den Fehler einbauende Entwickler ihn auch wieder behoben. Das ist doch immerhin schon mal ein gutes Zeichen. Oder nicht?

Carsten Eilers