Log4j – warum Open Source kaputt ist
Im Dezember 2021 sorgte die Sicherheitslücke Log4Shell in dem Logging-Framework Log4j für Java für Aufregung, die vom BSI als kritisch eingeschätzt und auf Warnstufe Rot eingestuft wurde. Nachdem sich der Staub inzwischen gelegt hat, ist es an der Zeit für einen Review: Was lässt sich aus alldem lernen?
- Golo Roden
Im Dezember 2021 sorgte die Sicherheitslücke Log4Shell in dem Logging-Framework Log4j für Java für Aufregung, die vom BSI als kritisch eingeschätzt und auf Warnstufe Rot eingestuft wurde. Nachdem sich der Staub inzwischen gelegt hat, ist es an der Zeit für einen Review: Was lässt sich aus alldem lernen?
Log4j ist praktisch der De-Facto-Standard für Logging in Java. Dennoch handelt es sich bei dem Framework lediglich um ein Werkzeug für Logging, ein Thema, das eher unspektakulär und wenig aufregend klingt. Doch trotzdem (oder vielleicht auch gerade deshalb) verbarg sich in dem Modul eine eklatante Sicherheitslücke, deren Details im CVE 2021-44228 näher beschrieben werden.
Über die technischen Details der Sicherheitslücke, das Angriffsszenario und Strategien zum Schließen der Lücke wurde in den vergangenen Wochen sehr viel berichtet, weshalb es wenig sinnvoll ist, das alles noch einmal zu wiederholen.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
Doch es stellen sich darüber hinaus Fragen, die bislang nur wenig diskutiert worden sind, die aber mehr Aufmerksamkeit verdient hätten. Dazu zählt zum einen, welche Ursachen und Gründe es für dieses Problem gibt, wie die ganze Situation überhaupt entstehen konnte, was sie begünstigt hat. Das ist die Frage nach dem "warum". Zum anderen stellt sich die Frage, was sich daraus lernen lässt: Wie lässt sich ein derartiges Fiasko zukünftig verhindern?
Kulturelle und gesellschaftliche Gründe
Dafür gibt es technische, vor allem aber auch kulturelle und gesellschaftliche Gründe. Der kulturelle Grund ist, dass Java an sich Komplexität fördert. Einfache Lösungen werden nicht favorisiert, sondern es wird auf Komplexität gebaut – und die Log4Shell-Thematik ist das Ergebnis überbordender Komplexität, die nicht mehr zu überblicken oder gar zu meistern ist. Das hat Kristian Köhntopp vor einigen Wochen auch in seinem hervorragenden Kommentar zu Log4j: Es funktioniert wie spezifiziert beschrieben.
Der gesellschaftliche Grund ist, dass zwar faktisch alle Unternehmen sich bei Open Source bedienen und davon abhängen, im Gegenzug aber kaum ein Unternehmen bereit ist, auch etwas beizusteuern oder zurückzugeben. Lizenzen wie AGPL & Co., die die eigentlich viel ehrlicheren Open-Source-Lizenzen sind, weil sie nicht nur Rechte einräumen, sondern auch Pflichten einfordern, werden von nahezu allen Unternehmen als Ausschlusskriterium behandelt, und stattdessen lieber auf die bequemen Alternativen MIT & Co. gesetzt. Und warum?
Weil es zumindest kurzfristig weniger kostet: Weniger Zeit und vor allem weniger Geld. Aber das ist eben nur eine kurzfristig erfolgreiche Strategie. Langfristig wird dieser Ansatz schiefgehen, und genau das ist jetzt mit Log4Shell eindrucksvoll passiert. Doch auch jetzt ist es einfacher, auf Open Source und die Entwicklerinnen und Entwickler dahinter zu schimpfen als sich proaktiv für ein nachhaltiges Modell einzusetzen, das Open Source für alle Beteiligten zum Vorteil werden lässt – nicht nur für die Verwender, sondern auch für die Menschen, die Open Source entwickeln.
Ein Geschäftsmodell für Open Source
An diesem Missstand muss sich dringend etwas ändern. Was wir als IT-Branche benötigen, ist ein tragfähiges Geschäftsmodell für nachhaltige Open-Source-Software. Und wir als Entwicklerinnen und Entwickler von Open Source müssen aufhören, unsere Zeit zu verschenken, als sei sie nichts wert.
Nur dann haben wir eine Chance, dass Open Source ein langfristig erfolgreiches und zugleich auch faires Modell werden kann, das nicht einseitig die belastet, die den Erfolg von Open Source erst ermöglichen. ()
