Log4Shell: Open Source als Gefahr für die Software-Lieferkette

Inhaltsverzeichnis

Was passiert, wenn sechs aktive Maintainer in ihrer Freizeit unbezahlt eine Codebase verwalten, welche in hunderten von Produkten zum Einsatz kommt, die große Teile unseres digitalen Alltags aufrechterhalten? Das haben wir kurz vor Weihnachten 2021 mit der Log4Shell-Lücke eindrucksvoll vor Augen geführt bekommen. Diese Sicherheitslücke in der Java-Logging-Bibliothek Log4j hat wohl so ziemlich jedem, der irgendwas mit dem Verwalten von Quellcode oder dem Administrieren von Software zu tun hat, klargemacht, wie gefährlich Software-Abhängigkeiten im eigenen Code sein können.

Eine Analyse von Fabian A. Scherschel

Fabian A. Scherschel schrieb von 2012 bis 2018 als Redakteur täglich für heise online und c't, zuerst in London auf Englisch, später auf Deutsch aus Hannover. Seit 2019 berichtet er als freier Autor und unabhängiger Podcaster über IT-Sicherheit, Betriebssysteme, Open-Source-Software und Videospiele.

In einem Online-Dialog zwischen Christian Grobmeier vom Log4j-Projekt und dem Leiter der Open Source Security Foundation (OpenSSF), Brian Behlendorf, stellte das Bundesamt für Sicherheit in der Informationstechnik (BSI) am Dienstag die Frage, was wir aus den Konsequenzen dieser Sicherheitslücke lernen können.

Die Software-Lieferkette ist in Gefahr

Behlendorf von der OpenSSF, einem Projekt unter der Schirmherrschaft der Linux Foundation, betonte, dass Log4Shell vor allem gezeigt habe, wie wackelig das Sicherheitsgerüst der "Software-Lieferkette" sei. Denn genau so müssten Open-Source-Entwickler jetzt denken, meint Behlendorf. Was oft schlicht als Software-Abhängigkeiten oder Dependencies bezeichnet werde, sei fester Teil der Lieferkette des Endproduktes. Entwickler könnten nicht mehr einfach irgendwelchen Code in ihre Projekte einbetten, nur weil es dafür bereits eine Bibliothek gäbe; stattdessen müssten sie sich Gedanken machen, wo diese Software herkäme, ob sie wirklich nötig sei und – letztendlich auch – ob sie sicher ist.

Auch Grobmeier vom Log4j-Entwicklerteam, der von der anderen Seite auf die Software-Abhängigkeiten schaut, sieht hier große Probleme. Aktuell seien immer noch 34 Prozent der täglichen Downloads von Log4j Versionen, die für die Sicherheitslücke CVE-2021-44228 anfällig seien. Eine Sicherheitslücke, die nunmehr seit mehr als 15 Monaten gepatcht ist. Trotzdem führen die Prozesse beim Verteilen der Java-Logging-Bibliothek – das was Behlendorf als Software-Lieferkette bezeichnet – dazu, dass immer noch haufenweise andere Software verwundbare Versionen von Log4j einbettet. Die Natur moderner Software-Entwicklung, in diesem Fall bei Java, mache es unmöglich, zu verhindern, dass andere Projekte verwundbare Versionen von Log4j herunterladen und im eigenen Code weiterverwenden.

Fundamentales Problem bei der Open-Source-Entwicklung

Diese Schwachstelle in der Lieferkette ist vor allem ein Problem von Open-Source-Software. Aber da, wie Behlendorf betont, Open-Source-Software dieser Tage in so gut wie allen Produkten steckt, die irgend eine Art von Software verwenden, ist dieses Problem ein gesamtgesellschaftliches. Laut Behlendorf hat die US-Regierung das Problem spätestens nach Log4Shell verstanden. Das Weiße Haus sei darum bemüht, diesen Teil der digitalen Infrastruktur besser abzusichern. In den USA denkt man über neue Gesetze nach, die Software-Firmen für Sicherheitslücken finanziell verantwortlich machen.

Behlendorf betont, dass sich die OpenSSF dafür einsetze, dass vor allem die Endanbieter von Software-Produkten haftbar gemacht werden. Nur so könne man verhindern, dass die Verantwortung auf die Entwickler in Open-Source-Projekten abgewältzt werde. Log4j-Entwickler Grobmeier pflichtete dieser Bedingung eindringlich bei: Als unbezahlter Entwickler, der an Log4j in der Freizeit arbeite, müsse er sofort aus der Entwicklung aussteigen, wenn man ihn rechtlich für Sicherheitslücken belangen könne. Ihm sei das Risiko für den Lebensunterhalt seiner Familie zu groß.

So werden wohl die meisten ehrenamtlichen Open-Source-Entwickler denken. Und auch Firmen, die ihre Entwickler dafür bezahlen, an Open-Source-Projekten zu arbeiten, um etwas an jene Community-Projekte zurückzugeben, die in den eigenen Produkten zum Einsatz kommen, werden sich dieses Engagement wohl zweimal überlegen, falls auf einmal Schadensersatzfoderungen für etwaige Programmierfehler im Raum stehen.

Nach Audits auch die Projekt-Entwickler bezahlen

Ebensowichtig sei es aber auch, Open-Source-Programmierern unter die Arme zu greifen, betonte Behlendorf. Das sei eine der Aufgaben der Open Source Security Foundation. Die Software, die große Teile des öffentlichen Internets trage, müsse rigorosen Sicherheits-Audits unterzogen werden. Aber das alleine reiche nicht, so Behlendorf. Man müsse nicht nur die Sicherheitsforscher bezahlen, die diese Audits ausführen, sondern auch die Entwickler, welche die gefundenen Lücken im Anschluss stopfen.

Auch da stimmte Grobmeier vom Log4j-Team zu: Man könne von Hobby-Entwicklern, die sowieso schon einen signifikanten Teil ihrer Freizeit dafür opfern, ruhmlos Software zu entwickeln, welche die halbe Welt nutze, aber eigentlich kaum jemanden interessiere, weil sie "langweilig" und "nicht wirklich cool" sei, jetzt auch noch erwarten, Sicherheits-Experten zu werden. Dafür hätten Leute wie er neben Job und der Software-Entwicklung einfach keine Zeit.

Im Anschluss an die große Log4Shell-Panik habe er sich einen Vortrag bei der Sicherheitskonferenz Blackhat angesehen, wo ein paar Jahre zuvor genau über solche JNDI-Injection-Angriffe berichtet worden sei, wie sie auch Log4j zum Verhängnis wurden, sagte Grobmeier. Bis zu diesem Zeitpunkt habe er gar nicht gewusst, was die Blackhat-Konferenz sei. Dem Log4j-Team habe zwischen diesem Blackhat-Vortrag und dem Bekanntwerden der Log4Shell-Lücke auch niemand von diesen Erkenntnissen berichtet. Durch das Desaster sei ihm klar geworden, wie wichtig Sicherheit bei der Software-Entwicklung sei. Bei der BSI-Diskussion gab er sich viel Mühe, anderen Open-Source-Entwicklern nahezulegen, Hilfestellungen wie die der OpenSSF mit offenen Armen anzunehmen.

Kein Blick über den Tellerrand

Leider wurde im Rahmen der BSI-Veranstaltung nicht deutlich, was in Deutschland getan wird, um die Konsequenzen von Sicherheitslücken wie Log4Shell in Zukunft zu verhindern oder zumindest abzufedern. Alle Teilnehmer waren sich einig, dass die Sicherheit von Open-Source-Projekten als grundlegender Teil der Lieferkette von fast allen Software-Produkten extrem wichtig ist.

In Online-Workshops wie dem hier beschriebenen gibt sich das BSI zwar Mühe, Interessenvertreter aus Wirtschaft, der Regierung und dem öffentlichen Leben zusammenzubringen – Dienstagabend wurde allerdings deutlich, dass vielen Beteiligten das Verständnis der gesamtgesellschaftlichen Brisanz des Themas nicht bewusst ist. Eine Gesellschaft, die unisono – von Seiten der Wirtschaft, der Regierung und auch der Presse – immer wieder lautstark für eine Beschleunigung der Digitalisierung in fast allen Bereichen des öffentlichen Lebens eintritt, müsste eigentlich Sicherheitsprobleme, wie sie hier in einem zweistündigen Dialog beleuchtet wurden, mit höchster Priorität angehen.

Alles am Netz ohne Netz und doppelten Boden

Wer den bargeldlosen Zahlungsverkehr als alternativlos ansieht, große Teile der Verkehrsinfrastruktur von digitalen Steuereinheiten abhängig machen will, kritische Infrastruktur bedingungslos vernetzt und die Wirtschaft auf Biegen und Brechen in die Cloud verlegen will, sollte sich eigentlich vorher überlegen, wie die Grundlagen für diese Pläne abgesichert werden können. Entsprechende Fragen unsererseits wurden allerdings in der Diskussion immer wieder übergangen.

Es ist gut zu wissen, dass das Log4j-Projekt seine Sicherheitsprobleme jetzt im Griff hat. Und ebenso ermutigt es, zu erfahren, welche Pläne die OpenSSF verfolgt, um ähnlichen Projekten unter die Arme zu greifen, bevor der große Knall auch bei ihnen die Weihnachtsferien der Entwickler ausfallen lässt, weil das gesamte Internet still steht.

Aber es scheint, als ob bisher niemand die gesamtgesellschaftlichen Konsequenzen für die Digitalisierung aus der Log4Shell-Schwachstelle gezogen hat. Wenn schon Veranstaltungen unter der Beteiligung von Kern-Entwicklern wichtiger Open-Source-Projekte unter der Ägide des BSI diesen Security-First-Ansatz vermissen lassen, wird er weiten Teilen der Zivilgesellschaft wohl kaum zuteilwerden.

(fab)