zurück zum Artikel

Der Zufallszahlengenerator der freien Krypto-Bibliothek liefert unter bestimmten Voraussetzungen relativ kurz hintereinander dieselben Zahlen. Noch ist nicht entschieden, ob die OpenSSL-Entwickler oder -Nutzer ihren Code ändern müssen.

Wenn ein Prozess sehr viele Kindprozesse hat, die über die Krypto-Bibliothek OpenSSL Zufallszahlen abrufen, den Zufallszahlengenerator aber nicht selbst initialisieren, kommen eventuell innerhalb des Programms die gleichen Zufallszahlen mehrfach zu Anwendung. Konkret bedeutet das, dass sich zum Beispiel Verschlüsselung unter Umständen knacken ließe. Noch ist nicht entschieden, ob die OpenSSL-Entwickler oder -Nutzer ihren Code ändern müssen.

Das Problem [1] tritt auf, wenn das Hauptprogramm zunächst den Zufallszahlengenerator (PRNG, pseudo random number generator) initialisiert und danach mit dem Unix-Systemaufruf fork neue Kind-Prozesse erzeugt. Diese Kinder bekommen eine eindeutige Prozess-IDs (PID). Die OpenSSL-Bibliothek verwendet diese PID intern, damit danach nicht alle Sub-Prozesse die gleichen Zufallszahlen bekommen. Allerdings gibt es im Betriebssystem-Kern einen Maximalwert für die PID: Ist er erreicht, bekommt der nächste Prozess eine niedrige ID, die noch kein anderer verwendet. Dadurch kann ein Child dieselbe PID erhalten wie ein früher erzeugtes und dann von OpenSSL dieselbe Zufallszahlensequenz geliefert bekommen.

Das trat in der Vergangenheit bereits bei PostgreSQL [2] und Android auf. Ein Angreifer könnte somit versuchen, Zufallszahlen zu erraten und so an kryptografisch gesicherte Informationen zu gelangen. Entdeckt [3] hatte das Problem der Ruby-Entwickler Eric Wong bereits 2011. Damals waren die OpenSSL-Entwickler jedoch der Auffassung, das Auftreten des Bugs liege an einer unsachgemäßen Nutzung der Bibliothek. Folglich bauten die PostgreSQL- und Android-Programmierer Workarounds, die entweder in jedem Child-Prozess den PRNG neu initialisieren [4] oder ihn mit einem besseren Startwert [5] versehen.

Bei den OpenSSL-Entwicklern beginnt jetzt das Nachdenken [6] darüber, ob sie zusätzliche Parameter wie die Uhrzeit zum Starten des PRNG verwenden sollten. Auf ein externes Pseudo-Zufallsgerät, wie es Linux mit /dev/urandom bietet, wollen sie sich bislang nicht einlassen, da derlei zu betriebssystemabhängig sei.

Unklar ist, wie weit das Problem überhaupt verbreitet ist. Unter Mac OS X 10.8 ließ es sich mit dem veröffentlichten Beispiel-Code ebenso wenig reproduzieren wie unter Oracles Linux 6.4 und Fedora 16 mit einem Linux-Kernel 3.4.2. Dort lieferte der PRNG trotz identischer PID jeweils verschiedene Ergebnisse. Bei einem Debian mit Linux 3.2.0 hingegen trat das beschriebene Phänomen auf, nachdem das Programm 32077 Child-Prozesse erzeugt hatte. (ck [7])

URL dieses Artikels:
https://www.heise.de/-1942299

Links in diesem Artikel:
[1] http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/
[2] http://www.postgresql.org/message-id/E1UKzBn-0006c2-Cy@gemulon.postgresql.org
[3] http://marc.info/?l=openssl-dev&m=130289811108150
[4] http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=21ce40c8eab4d0da110fb6e05e9d9ec20d73d8b3
[5] http://android-developers.blogspot.de/2013/08/some-securerandom-thoughts.html
[6] http://marc.info/?l=openssl-dev&m=137719278521474&w=2
[7] mailto:ck@ix.de

Copyright © 2013 Heise Medien