Log4j: Was sich an Open Source dringend ändern muss

Jeden Dienstag beschäftigen wir uns im Pro-Briefing mit einem wichtigen Thema der IT. Heute geht es um Open Source und IT-Sicherheit. Den Impuls gab die Log4j-Schwachstelle. Eine Schwachstelle in der Java-Logging-Bibliothek Log4j hält die Branche in Atem. Entdeckt und publiziert wurde LogShell4 – wie die Schwachstelle heißt – am Freitag. Seitdem sind IT-Fachkräfte damit beschäftigt, betroffene Systeme zu identifizieren und gegen Angriffe zu verteidigen. Eingesetzt wird Log4j flächendeckend. Betroffen sind Behörden, kleine Anwendungen, Konzerne wie Apple, Amazon und Tesla – sozusagen alle. Mittlerweile gibt es Listen von betroffener Software. IT-Sicherheitsexpert:innen empfehlen jedoch, dass auch Systeme überprüft werden, die nicht in einer dieser Listen auftauchen. Neben Linux- und Windows-Servern könnten auch Firewalls, Logging-Server, Hypervisors und andere Systeme betroffen sein, auf denen potenziell Java zum Einsatz kommen kann. Auch Industriemaschinen könnten betroffen sein. IoT-Systeme sollten deshalb ebenfalls geprüft werden. Angreifer:innen scannen derweil das Internet mithilfe von Tools nach angreifbaren Systemen. Kurzum ist es so, wie Wired am Sonntag titelte: Das Internet brennt. Was ist Log4j und was ist die Schwachstelle? Kurz gesagt ist Log4j eine Logging-Library, ein Protokollwerkzeug. Sie protokolliert, was innerhalb von in Java geschriebenen Programmen passiert. Auf Basis dieser Logs können IT-Mitarbeiter:innen dann Fehler identifizieren. Version 1.0 wurde vor nicht ganz 21 Jahren veröffentlicht, seither ist die Bibliothek zu einer Art Standard für diese Art von Protokollierung geworden. Die Schwachstelle ist derart leicht auszunutzen, dass das Bundesamt für Sicherheit in der Informationstechnik (BSI) vergangene Woche die Warnstufe Rot ausgerufen hat. Vereinfacht gesagt, interpretiert die Logging-Library bestimmte Zeichenfolgen offenbar falsch. Enthalten sie Befehle, ermöglicht die Schwachstelle deren Ausführung auf dem betreffenden Server. So ziemlich alle Java-Anwendungen mit Verbindung zum Internet, in denen Log4j zur Protokollierung von Nutzer:innenanfragen zum Einsatz kommt, können so aus der Ferne übernommen werden. Die Entwicklung von Log4j wurde bisher von 3 Privatpersonen gesponsert Entwickelt und betreut wird die Open-Source-Software von Freiwilligen. Über sie brach über das Wochenende viel Ungnade herein, wie ein PMC-Mitglied der Apache Software Foundation auf Twitter berichtet: [twitter 1469349956880408583] Zwei Punkte sind daran bemerkenswert: zum einen, dass die Log4j-Maintainer bis zum Wochenende gerade einmal von drei Supportern – Michael, Glenn und Matt – gesponsert wurden. Obwohl die Software – in Anlehnung an einen xkcd-Comic – der buchstäbliche Pfeiler ist, auf den sich Teile der modernen digitalen Infrastruktur stützen. Zum anderen, dass die Schwachstelle offenbar ein Feature ist, das von den Entwicklern keiner wollte, das allerdings beibehalten wurde, um die Kompatibilität mit älterer Software zu sichern. Einzelne Unternehmen fordern jetzt, den am Freitag erstmals veröffentlichten Fix zusätzlich für ältere Versionen von Log4j anzupassen: [twitter 1470510060698804228] Einer der Maintainer, Ralph Goers, der den Fix für die Schwachstelle bereitgestellt hat, schreibt in seinem GitHub-Sponsors-Profil, dass er in Vollzeit als Software-Architekt tätig sei und sich dem Projekt in seiner Freizeit widme. Er habe immer davon geträumt, sich in Vollzeit der Arbeit an Open-Source-Projekten zu widmen, und freue sich über jede Unterstützung. Mittlerweile sind 85 neue Sponsoren hinzugekommen, darunter einige wenige Unternehmen, der Großteil sind allerdings Privatpersonen. Arbeit an Open-Source-Projekten muss angemessen bezahlt werden Denkt man einmal darüber nach, wie viel Geld es die Wirtschaft jetzt kostet, über die Schwachstelle ausgeführte Angriffe zu verhindern, wäre es um einiges günstiger gewesen, die Open-Source-Maintainer einfach angemessen für ihre freiwillige Arbeit zu bezahlen, sodass sie Zeit und Ressourcen gehabt hätten, einen Weg zu finden, die Schwachstelle ausfindig zu machen und zu beheben. Bleibt zu hoffen, dass Log4Shell in diesem Bereich zu einem Umdenken führt. Ein designierter Career-Path „Open Source Developer“ wäre denkbar – oder, dass Verträge zwischen nutzniesenden Konzernen und Maintainer:innen dafür sorgen, dass diese ihre Arbeit in Rechnung stellen können.