In dieser Ausgabe von "Standpunkt Sicherheit" erhalten Sie einige Hintergrundinformationen zu den von Debians OpenSSL-Paket erzeugten schwachen Schlüsseln und welche Folgerungen sich daraus ergeben. Welche Auswirkungen die Schwachstelle hat und was das für Sie bedeutet, können Sie in dem Text "Debian und die schwachen Schlüssel" nachlesen.

Was ist passiert?

Auslöser der Schwachstelle ist ein Patch, der mit der Version 0.9.8c-1 vom 17. September 2006 eingeführt wurde. Die Test-Tools Valgrind und Purify fanden Code-Zeilen, die für potenzielle Speicherlecks gehalten wurden:

MD_Update(&m,buf,j);
[...]
MD_Update(&m,buf,j); /* purify complains */

Um diese möglichen Schwachstellen zu beheben, sollten die beiden Zeilen auskommentiert werden. Bevor der Patch freigegeben wurde, wurde auf der OpenSSL-Developer-Mailingliste nachgefragt, was es damit auf sich hat und ob die Zeilen entfernt werden können. Da es keinen Widerspruch gab, wurden die Zeilen dann letztendlich auskommentiert und der Patch in die Debian-Portierung von OpenSSL eingepflegt. Das Problem dabei: Die Aufrufe dienten dazu, zufällige Ausgangswerte für die Erzeugung der Zufallszahlen zu erhalten. Der Patch führte dazu, dass die Funktion, die für das Sammeln der notwendigen Ausgangswerte für den Zufallszahlengenerator zuständig ist, nicht mehr funktionierte. Dadurch wurden überhaupt keine zufälligen Ausgangswerte erfasst und für die Bildung der Zufallszahlen nur noch die Linux-Prozess-ID verwendet. Die ist 16 Bit lang, und damit stehen pro gegebener Architektur, Schlüsseltyp und -länge nur 32.767 mögliche Werte zur Verfügung.

Wo hakts?

Ben Laurie, einer der OpenSSL-Entwickler, hat in einem Blog-Beitrag die Debian-Entwickler scharf angegriffen: "Vendors Are Bad For Security". Demnach sollen die Linux-Distributoren die Finger vom Sourcecode lassen und Änderungen den eigentlichen Entwicklern überlassen. Er hat daraufhin bereits reichlich Gegenwind bekommen, aber betrachten wir das ganze doch mal von Anfang an:

Die Diskussion auf der OpenSSL-Developer-Mailingliste ist nicht unbedingt optimal gelaufen: Die könnte man auch so verstehen, als ob die Zeilen nur für den Debug-Vorgang entfernt werden sollten und nicht auch in der produktiv eingesetzten Version. Irreführende Warnungen oder Fehlermeldungen durch solche Änderungen zu unterdrücken, ist nicht unbedingt unüblich. Wenn das Programm dann am Ende fertig ist und zufriedenstellend funktioniert, werden die Kommentarzeichen wieder entfernt und die Endversion kompiliert und getestet. In sofern war es also ein verständliches "aneinander vorbeireden". Es wäre sicher besser gewesen, klar zu sagen, dass die produktive Version für Debian geändert werden sollte. Ein Hinweis wie "Ich bin der Maintainer für OpenSSL für Debian und habe folgendes Problem..." oder Ähnliches wäre da sicher hilfreich gewesen. Aber selbst wenn das mögliche Mißverständnis aufgefallen und aufgeklärt worden wäre - laut Ben Laurie wäre es am falschen Ort gewesen. Denn laut einem weiteren Blog-Beitrag von ihm wird die Mailingliste openssl-dev von den Entwicklern nicht regelmäßig gelesen, obwohl diese Liste auf der OpenSSL-Website als Ort für Diskussionen über die OpenSSL-Entwicklung angegeben wird:

Fifthly, I said that openssl-dev was not the way to ensure you had the attention of the OpenSSL team. Many have pointed out that the website says it is the place to discuss the development of OpenSSL, and this is true, it is what it says. But it is wrong. The reality is that the list is used to discuss application development questions and is not reliably read by the development team.

Die Beschreibung für openssl-dev auf der Seite OpenSSL Mailing Lists sagt tatsächlich etwas vollkommen anderes: "Discussions on development of the OpenSSL library. Not for application development questions!". Dieser Widerspruch sollte vielleicht mal aufgeklärt werden. Inzwischen hat Ben Laurie seine Aussage auch korrigiert: Mindestens einer der Entwickler liest die Mailingliste doch regelmäßig.

Ein Kommentar dazu erübrigt sich ja eigentlich. Vielleicht sollten die OpenSSL-Entwickler erst einmal die Fehler in ihren Kommunikationsstrukturen beheben, bevor sie über andere herziehen. Wenn einer nicht weiß, was der andere macht, verläßt sich am Ende jeder auf einen, der gar nichts macht. Wenn eine Mailingliste als Ort für Diskussionen über die Entwicklung eines Programms angegeben wird, muss auch sichergestellt werden, dass diese Liste immer von mindestens einem Entwickler gelesen wird. Und nicht nur, wenn zufällig jemand Lust dazu hat. Was ist, wenn der Entwickler, der die Liste jetzt liest, überraschend ausscheidet? Besonders gut organisiert scheint mir das ganze nicht zu sein.

Änderungen unerwünscht?

Bleibt ein letzter Punkt: Dürfen Linux-Distributoren Programme ändern? Natürlich. Zum einen ist eine Linux-Distribution ein komplexes Paket verschiedenster Programme, die alle zusammen funktionieren müssen. Um diese Zusammenarbeit erreichen zu können, sind immer Anpassungen notwendig. Sei es, damit alle Programme mit den verwendeten Bibliotheksversionen funktionieren, sei es, damit sie auf allen unterstützten Plattformen laufen. Zum anderen unterstützen Linux-Distributionen Programmversionen oft deutlich länger als es die jeweiligen Programmentwickler tun, und das macht das Rückportieren von Patches oder deren Neuentwicklung notwendig.

Wenn das nächste Mal auf irgendeinem System etwas mit OpenSSL nicht funktioniert - soll ich mich dann an den Support für das System oder den für OpenSSL wenden? Ist es nicht gerade der Zweck von Distributoren, ein funktionierendes System bereit zu stellen und zu warten? Wenn die OpenSSL-Entwickler bereit sind, in Zukunft lauffähige Versionen für alle möglichen Kombinationen von Betriebssystem, Bibliotheksversionen, Hardwareplattformen usw. usf. bereitzustellen - nur zu. Ansonsten sollten sie das denen überlassen, die sich damit auskennen, und sie ggf. unterstützen. Die Angabe bzw. der Aufbau brauchbarer Kommunikationstrukturen wäre da schon ein erster Schritt.

Ach, und was war doch noch mal ein Zweck von Open Source Software? Irgendwie meine ich, mich da an etwas wie "Eigene Änderungen vornehmen" zu erinnern, aber vielleicht sehen die OpenSSL-Entwickler das ja auch anders.

Ob und wie die Änderungen dann in das Originalprogramm einfließen, ist eine andere Frage. In diesem Fall sind die Änderungen ganz gewaltig in die Hose gegangen, aber das ist kein Grund, Änderungen durch Dritte generell zu verteufeln. Vielleicht führt das aktuelle Problem aber dazu, die Zusammenarbeit zwischen den einzelnen Gruppen zu verbessern. Denn wie oben zu sehen war, wurde bei Debian davon ausgegangen, das OK der OpenSSL-Entwickler bekommen zu haben. Dass die über die laut Beschreibung eigentlich dafür vorgesehen Mailingliste unter Umständen gar nicht erreichbar sind, konnte schließlich niemand ahnen.

Und ein letzter Punkt: Im Original-Quelltext steht einmal der Kommentar /* purify complains */, in einem "#ifndef PURIFY"-Block - den Entwicklern war also durchaus bekannt, das Testtools den entsprechenden Code bemängeln. Wäre dann nicht ein etwas auführlicherer Kommentar, warum dieser an und für sich gefährliche Code trotzdem verwendet wird, angebracht? Natürlich kann man nicht jede einzelne Zeile kommentieren, aber gerade bei einem Programm aus dem Sicherheitsbereich wäre in solchen Zweifelsfällen ein besserer Kommentar als "Testprogramm meckert" angebracht.

Carsten Eilers