Log4Shell – eine Sicherheitslücke in einer Open-Source-Bibliothek hält die IT-Abteilungen der Welt auf Trab

Was ist passiert?

Eine sehr weitverbreitete Bibliothek für die Protokollierung in Java-Anwendungen (log4j) hat eine Schwachstelle, über die ein Angreifer beliebigen Code von einer externen Ressource, d.h. vom Angreifer selbst, nachladen kann. Dafür kommt eine Funktion zum Einsatz, die als Teil von Java spezifiziert ist. Es handelt sich also nicht einfach um eine überbordende Funktionalität der Bibliothek, sondern um eine ungünstige Umsetzung eines gewünschten Verhaltens der Programmiersprache, die sich jedoch an dieser Stelle sehr leicht ausnutzen lässt. Genauere Analysen der Schwachstelle sollen hier nicht stattfinden – das haben schon andere Blogger, Entwickler und News-Seiten getan.

Wer ist betroffen?

Diese Frage lässt sich leider nicht so einfach beantworten. Die Bibliothek ist in unzähligen Anwendungen integriert. Das bedeutet, sie ist eventuell Teil der Software, die bei Ihnen im Einsatz ist oder die Sie entwickeln. So genau weiß man das immer nicht. Diejenigen Software-Entwickler, die log4j direkt einsetzen, können ihre Kunden informieren. Allerdings ist log4j in manchen Fällen auch als Abhängigkeit einer Abhängigkeit in eine Anwendung gerutscht. Hier den Überblick zu behalten, ist enorm schwierig. Hat man ihn über die im eigenen Betrieb eingesetzte Software, können die Hersteller ggf. Informationen liefern. Doch auch die Community ist nicht untätig.

Was kann man tun?

Nicht allzu viel. Am besten ist es natürlich, eine betroffene Software upzudaten und so die Sicherheitslücke zu schließen. Doch ist nicht immer abschätzbar, wie lange es dauert, bis Patches verfügbar sind. Und dann sind da noch Anwendungen, die zwar unternehmenskritisch sind, welche aufgrund ihres Alters jedoch nicht mehr auf dem Markt sind oder von den Entwicklern nicht länger unterstützt werden.

Man kann die verantwortliche Funktion – das Nachladen von Code aus externen Quellen –auch durch Umgebungsvariablen oder Startparameter von Java abschalten. Ob die betroffene Anwendung dann noch wie gewohnt funktioniert, ist nicht sicher. Womit man auf jeden Fall rechnen muss: Die Protokollierung wird weniger aussagekräftig sein als vorher, da bestimmte Informationen nicht mehr von außen eingeholt und in die Protokollnachrichten integriert werden können.

Ein Filtern der Anfragen ist übrigens wenig zielführend – zu einfach ist es, die Anfrage zum Nachladen von externem Code zu verschleiern.

Wer ist schuld?

Hier findet man in Artikeln, Analysen und Foren verschiedenste Sündenböcke, darunter:

• Die Entwickler der Bibliothek, die die Bibliothek in ihrer Freizeit entwickeln
• Open-Source-Software im Allgemeinen
• Entwickler, die die Bibliothek nutzen, ohne die ursprünglichen Entwickler der Bibliothek zu unterstützen
• Entwickler, die ihre Software nur noch aus verschiedenen Paketen „zusammenstöpseln“, ohne viel Eigenarbeit zu investieren, und die dadurch nicht alle Bestandteile der Software kennen
• Java aufgrund der grundlegenden Funktionalität

Dabei ist es weder sinnvoll noch fair, einen einzigen Schuldigen zu nennen. Hier spielen viele Aspekte eine Rolle, von der gewählten Lizenz über die Verbreitung bis hin zur modernen Software-Entwicklung.

Fazit

Log4j entwickelt sich zu einem Flächenbrand in der IT. Doch einen einzigen Brandherd, einen einzigen Brandstifter gibt es nicht. Eine genaue und möglichst neutrale Analyse der Verknüpfungen wird erst dann möglich sein, wenn man die momentane Situation mit etwas Abstand betrachten kann.