Log4J: Erstes Update für Log4Shell-Lücke nicht vollständig

Das Log4J-Team musste das Update für die Sicherheitslücke Log4Shell nachbessern. Die eigentliche Ursache des Fehlers steht nicht mehr bereit.

Artikel veröffentlicht am 15. Dezember 2021, 11:08 Uhr, Sebastian Grüner

Die Lücke in der Java-Anwendung Log4J wird durch das Deaktivieren von JNDI wohl komplett geschlossen. (Bild: Pixabay)

Die Entwickler des Logging-Werkzeugs Log4J haben mit den Versionen 2.16 und 2.12.2 erneut sicherheitskritische Notfallupdates veröffentlicht. Geschlossen wird damit nun die Sicherheitslücke CVE-2021-45046, bei der es sich offenbar um eine Erweiterung der auch als Log4Shell bezeichneten Sicherheitslücke (CVE-2021-44228) handelt, die Ende der vergangenen Woche bekanntgeworden ist. Offenbar waren die ersten Fehlerbehebungen hierfür nicht vollständig.

In der Sicherheitsmeldung des Projekts heißt es dazu: "Es wurde festgestellt, dass der Fix (...) in bestimmten nicht standardmäßigen Konfigurationen unvollständig war". Und weiter heißt es mit Bezug auf die konkreten Voraussetzungen: "Dies könnte Angreifern (...) ermöglichen, bösartige Eingabedaten mithilfe eines JNDI-Lookup-Musters zu erstellen, was zu einem Denial-of-Service-Angriff (DOS) führt".

Vorkehrungen helfen nur bedingt

Betroffen davon seien wiederum sämtliche bisher verfügbaren Versionen von Log4J 2, also 2.0-beta9 bis 2.12.1, sowie die Versionen 2.13 bis 2.15. Darüber hinaus warnt das Team, dass die bisher offiziell empfohlene Vorkehrung, die Systemeigenschaft Log4j2.noFormatMsgLookup auf true zu setzen, das Ausnutzen der spezifischen neuen Lücke nicht verhindert. Anwender, die dies umgesetzt haben, könnten also ohne die neuen Patches auch weiter angreifbar sein.

Da die neue Lücke für die bisher unvollständig gepatchte Version laut dem Entwicklungsteam nur unter ganz bestimmten Voraussetzungen ausgenutzt werden kann und es sich dabei um einen Denial-of-Service-Angriff handelt, wird die Lücke noch mit einem "moderaten" Sicherheitslevel bezeichnet. Das Sicherheitsunternehmen Luna Sec widerspricht dem jedoch bedingt, da sich je nach eingespielten Patches und Vorkehrungen für die erste Lücke nun auch die zweite Lücke weiter zum Ausführen von Code (Remote Code Execution, RCE) eignen könnte.

Darüber hinaus schreibt der Sicherheitsforscher Márcio Almeida, dass es ihm gelungen ist, die ursprüngliche Lücke auch dann ausnutzen zu können, wenn die Java-Einstellung trustURLCodebase=false genutzt wird. Auch diese Konfiguration wurde zuvor als mögliche Vorkehrung gegen die ursprüngliche Lücke beschrieben und wird standardmäßig in einigen aktuellen Versionen des JDK genutzt. Einige Betroffene könnten sich damit eventuell in falscher Sicherheit gewogen und mit dem Einspielen von Patches gewartet haben, was sich mit dem Code von Almeida als trügerisch herausstellt.

Updates einspielen oder JNDI entfernen

Die offizielle Vorgehensweise, um die JNDI-Lücken in Log4J zu beheben, ist nun laut dem Team ein Update auf Version 2.16 für Java 8 oder neuere Versionen. Für Java 7 stellt das Team außer der Reihe das Update 2.12.2 bereit. Alle anderen Nutzer sollen, wie bereits beschrieben, die betroffene Klasse für den JNDI-Lookup aus ihren Installationen löschen: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Das Team weist außerdem darauf hin, dass von den Lücken nur die Jar-Datei Log4J-Core betroffen ist. Anwendungen, die lediglich die Jar-Datei Log4J-API verwenden, seien nicht betroffen.

In der aktuellen Version 2.16 von Log4J haben die zuständigen Entwickler nun außerdem den Code vollständig dafür entfernt, dass aus den Log-Nachrichten heraus überhaupt ein JNDI-Lookup ausgeführt werden kann. Das war die grundlegende Ursache für den Fehler und wurde bereits mit der vorhergehenden Version 2.15 verhindert, nun fehlt also der Code dazu.

Mit Version 2.16 wird außerdem die Möglichkeit eines JNDI-Lookups in der restlichen Anwendungslogik standardmäßig deaktiviert. Dazu heißt es in den Release Notes: "Das Log4j-Team ist der Ansicht, dass die standardmäßige Aktivierung von JNDI ein unangemessenes Risiko für unsere Benutzer darstellt."

JNDI-Lookups sind zwar nach Aktivieren der Systemeigenschaft log4j2.enableJndi in Log4J weiter möglich, das Team rät aber deutlich von der Nutzung ab. Das Team schreibt: "Die Verwendung von JNDI in einem ungeschützten Kontext stellt ein großes Sicherheitsrisiko dar und sollte sowohl in dieser Bibliothek als auch in allen anderen Java-Bibliotheken, die JNDI verwenden, als solches behandelt werden."