log4j: Desaster oder Erfolgsstory?
Langsam glätten sich die Wogen um log4j wieder. Zur Erinnerung: Im Dezember wurde eine gravierende Sicherheitslücke in diesem quelloffenen Softwarepaket bekannt. Unter dem Namen Log4Shell ermöglichte diese Angreifern, beliebigen Softwarecode auf Rechnern auszuführen, die log4j einsetzen. Da log4j ein weit verbreitetes Framework für das Loggen von Anwendungsmelden ist, waren die Auswirkungen gravierend.
In diesem Artikel geht es nicht darum, wie log4j funktioniert oder was der wirtschaftliche Schaden ist. Statt dessen geht es um die Frage, warum log4j überhaupt so erfolgreich war und was der Vorfall für Open Source bedeutet.
Warum war log4j so erfolgreich?
Die Auswirkungen von Log4Shell waren so enorm, weil dermaßen viele Unternehmen das Framework einsetzten. Das ist erst einmal ein Kompliment für Open Source, und nicht das Gegenteil. Weite Verbreitung bedeutet schließlich, dass die Software einen hohen Nutzen hatte (und ein attraktives Preis-Leisungs-Verhältnis).
Interessant ist allerdings, dass viele Unternehmen gar nicht wussten, dass sie betroffen waren. Denn wenige Unternehmen verwenden log4j direkt. Die meisten Unternehmen verwenden Open Source-Software oder Open Source-Komponenten in ihren Projekten. Diese verwenden wiederum offene Komponenten. Selbst eine einfache Anwendung ist oft tief verschachtelt.
Das folgende Bild zeigt die Abhängigkeiten von Softwarekomponenten. Eine einfache Anwendung (grün) nutzt 11 Open Source-Komponenten (orange). Mehrere Ebenen tiefer taucht log4j auf (blau).
Um die Eingangsfrage zu beantworten: log4j war in der (Java-) Softwareentwicklung daher erfolgreich, weil es für viele das beste Loggingframework war (und das beste Preis-Leistungs-Verhältnis hatte). Durch den Erfolg von Softwarekomponenten wurde es dann in fast jede größere Entwicklung eingebunden. Den Nutzern war dies häufig nicht bewusst.
Bug oder Feature?
Das ironische an log4j ist, dass die Sicherheitslücke noch nicht einmal auf einem Bug basiert. Das Magazin Wired zitiert Free Wortley, der die Sicherheitslücke nicht als „Bug“, sondern „einen Entwurfsfehler von katastrophalem Ausmaß“ bezeichnet.
Das grundsätzliche Problem beim Design von log4j ist die Möglichkeit, ausführbaren Code nachzuladen. Weiterhin kann der Angreifer Daten über viele Kanäle an das Logging-System übergeben, zum Beispiel Chatnachrichten oder URLs.
Wer schreibt die Anforderungen?
Viele Open Source-Projekte entstehen oft aus dem persönlichen Bedarf eines Entwicklers. Dementsprechend sehen auch die Anforderungen aus, wenn diese überhaupt aufgeschrieben wurden. Das ist ja auch nicht wirklich schlimm. Anforderungen und Dokumentation folgen in dem Moment, wo sich eine Gemeinschaft entwickelt. Bezüglich der Priorisierung der Umsetzung von Anforderungen darf jeder mit anpacken. Doch oft packen die Mitarbeitenden die Aufgaben an, die ihnen Spaß machen. Wenige Entwickler übernehmen freiwillig die wichtigen aber langweiligen Aufgaben.
Wer bezahlt die Entwickler?
Damit jemand die wichtigen, aber langweiligen Tätigkeiten durchführt, muss diese Person in der Regel bezahlt werden. Doch nur wenige Entwickler werden direkt für Ihre Arbeit an Open Source bezahlt. Ausnahmen gibt es, zum Beispiel in Firmen wie Canonical (Ubuntu) oder Automattic (WordPress).
Viele Projekte werden auch aus Forschungsgeldern finanziert. Die Entwickler sind dann typischerweise Doktoranden oder wissenschaftliche Mitarbeiter. Doch in solchen Fällen kommen langweilige Themen – wie Sicherheit – ebenfalls zu kurz, da die Hauptanforderung die Unterstützung der Forschungsarbeit ist.
In der Wirtschaft werden Entwickler oft indirekt für Ihre Arbeit an Open Source bezahlt. Das klassische Beispiel ist ein Arbeitgeber, der dem Mitarbeitet gestattet, nebenbei ein Open Source-Projekt zu betreuen. Das passiert besonders dann, wenn das Projekt auch im Unternehmen eingesetzt wird. Doch auch in solchen Fällen machen Unternehmen selten Vorgaben, die über die Funktion hinausgehen.
Wen wundert es unter solchen Rahmenbedingungen, dass der Einsatz von Open Source Risiken mit sich bringt? Es gibt halt nichts umsonst.
TANSTAAFL – There ain’t no such thing as a free lunch
Robert A. Heinlein
Fazit: Risikomanagement
Dirk Riehle hat in seinem Blog vorgeschlagen, wie die Wirtschaft mit Open Source umgehen sollte. Das Stichwort: Risikomanagement. Der Einsatz von jeder Software – Open Source oder nicht – birgt Risiken. Diese zu verstehen ist die Aufgabe der Betreiber.
Interessanterweise ist Risikomanagement in Open Source bereits in bestimmten Bereichen etabliert: Due Dilligence bezüglich der verwendeten Lizenzen ist üblich. Unternehmen verstehen durchaus die Gefahren von Klagen, von denen es in den 2000ern schon viele gab.
Doch allein durch die steigende Komplexität von Software und den Stellenwert, den Software heute einnimmt, steigt die Dringlichkeit bezüglich Risikomanagement. Ein Anbieter von isolierter Desktop-Software kann sich da vielleicht noch durchmogeln. Aber der Großteil moderner Software ist vernetzt. Jedes Unternehmen sollte zumindest einen Notfallplan in der Schublade haben. Und in vielen Fällen auch ein Team, das Krisen schnell entschärfen kann.
Nicht vergessen: Log4Shell wurde „nur“ in einem Computerspiel entdeckt.
