Wer Open-Source-Software entwickelt, stellt seinen Code öffentlich zur Diskussion, fordert alle zur Fehlersuche auf, und profitiert von den Verbesserungen durch die Community. Doch das ist nur eine Seite der Medaille – wie überall gibt es eine zweite. Und die ist gefährlich.

Was, wenn ich einen Fehler in Linux entdecke? Gesetzt den Fall, ich kenne mich aus, kann ich einen Patch schreiben, der das Malheur behebt. Je nachdem, welches Subsystem des Kernels der Fehler betrifft, poste ich den Patch dann nebst Beschreibung des Problems und der Lösung zunächst auf einer der rund 200 Mailing-Listen, die zum Linux-Kernel gehören. Viele Mitstreiter, die die entsprechende Liste ebenfalls lesen, können damit in die Diskussion einsteigen: Ist das tatsächlich ein Fehler? Behebt ihn der Patch? Produziert er keine neuen Fehler? Sieht er elegant und effizient aus?

Mein Patch wird öffentlich begutachtet und diskutiert. Irgendwann gelangt er dann zum Maintainer des Subsystems, der ihn seinerseits unter die Lupe nimmt und womöglich Fragen an mich hat, Änderungen fordert – oder den Patch auch ganz verwirft, wenn er nichts damit anfangen kann. Nimmt er ihn aber an, pflegt er ihn in seinen Kernel-Tree ein.

Maintainer sind hierarchisch organisiert. Übergeordnete Lieutenants übernehmen die Patches von untergeordneten Maintainer. An der Spitze der Pyramide steht Linus Torvalds. Patches, die er akzeptiert – so Gott will, würde meiner dazugehören –, gelangen in den Mainline-Kernel und von dort später in die Kernel der verschiedenen Distributionen.

So ist es beinahe immer – doch es gibt Ausnahmen, vor allem dann, wenn der Patch eine gefährliche Sicherheitslücke betrifft. Die will natürlich niemand in der Öffentlichkeit breittreten, denn das würde böswillige Zeitgenossen ja einladen, die Lücke auszunutzen, bevor sie geschlossen werden kann. Solche Patches werden deshalb nur im kleinen Kreis und in geschlossenen Mailing-Listen diskutiert. Am Ende aber landen sie auf demselben Weg im Mainline-Kernel wie die anderen auch. Und gerade das ist ihr Verhängnis.

Forscher der University of Applied Sciences, Regensburg, der Uni Hannover und von BMW haben kürzlich gezeigt, dass sie automatisiert solche Patches finden können, denen keine öffentliche Diskussion vorausging. Das ist keineswegs trivial, denn es gibt keine maschinenlesbare Kennung, mit der sich eine E-Mail einfach einem Commit zuordnen ließe. Außerdem spielt die Menge eine Rolle: Zwischen zwei Major-Releases finden nicht selten mehr als 10 000 Patches Eingang in den Kernel. Mit einem ziemlichen Aufwand an Mathematik ist es aber dennoch möglich, die im Stillen erzeugten Patches auszufiltern. Ist so ein Flicken erst einmal identifiziert, hat man in den meisten Fällen eine ausnutzbare Sicherheitslücke gefunden – und das mindestens Tage, oft aber auch Monate, bevor das Gegengift in der Distribution ankommt, die der Anwender benutzt.

Damit ergibt sich ein echtes Dilemma: Der öffentliche Review-Prozess ist die Seele von Open Source, auf ihn kann man nicht verzichten. Ebenso unverzichtbar ist die Responsible Disclosure, also die verantwortungsvolle Offenlegung, die bedeutet, dass man Sicherheitslücken erst dann öffentlich vorstellt, wenn sie geschlossen werden können. Und doch erwächst aus der Kombination beider Prinzipien eine neue Bedrohung; vollkommene Sicherheit ist eben unmöglich.

Quasi als Abfallprodukt ihrer Forschung haben die Wissenschaftler übrigens eine zweite Gefahr aufgedeckt. Sie stießen nämlich auch auf Patches, die nicht öffentlich diskutiert wurden, obwohl sie kein Sicherheitsproblem betrafen. Manchmal wurde die Veröffentlichung der Patches “vergessen”, in einem Fall waren viele Entwickler eines Subsystems und der Maintainer bei ein und derselben Firma angestellt. Sie fanden es offenbar bequemer, die Angelegenheit auf dem kleinen Dienstweg zu regeln. Damit haben sie allerdings die öffentliche Kontrolle des Codes bewusst umgangen. Auch das ist gefährlich.

Jens-Christoph Brendel

Stellv. Chefredakteur