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 ,
Die Lücke in der Java-Anwendung Log4J wird durch das Deaktivieren von JNDI wohl komplett geschlossen.
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.

Stellenmarkt
  1. Digital Consultant (m/w/d)
    ORBIT Gesellschaft für Applikations- und Informationssysteme mbH, Bonn
  2. Senior Architect Microsoft Azure (m/w/d)
    operational services GmbH & Co. KG, Frankfurt am Main, Berlin, Dresden, München, Wolfsburg
Detailsuche

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.

Golem Akademie
  1. Netzwerktechnik Kompaktkurs: virtueller Fünf-Tage-Workshop
    14.–18. Februar 2022, virtuell
  2. Jira für Anwender: virtueller Ein-Tages-Workshop
    4. Februar 2022, virtuell
Weitere IT-Trainings

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.

Hacking & Security: Das umfassende Handbuch. 2. aktualisierte Auflage des IT-Standardwerks (Deutsch) Gebundene Ausgabe

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."

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed


Aktuell auf der Startseite von Golem.de
Musterfeststellungsklage
Parship kann eine Kündigungswelle erwarten

Die Verbraucherzentrale ruft zur Kündigung bei Parship und zur Teilnahme an einer Musterfeststellungsklage auf. Doch laut Betreiber PE Digital ist das aussichtslos.

Musterfeststellungsklage: Parship kann eine Kündigungswelle erwarten
Artikel
  1. Open Source: Antworten Sie innerhalb von 24 Stunden
    Open Source
    "Antworten Sie innerhalb von 24 Stunden"

    Die E-Mail eines großen Konzerns an den Entwickler von Curl zeigt wohl eher aus Versehen, wie problematisch das Verhältnis vieler Firmen zu Open-Source-Software ist.

  2. Elektromobilität: GM tätigt 7-Milliarden-Dollar-Investition für E-Autos
    Elektromobilität
    GM tätigt 7-Milliarden-Dollar-Investition für E-Autos

    General Motors gibt sieben Milliarden US-Dollar aus, um bis Ende 2025 in Nordamerika eine Million Elektroautos pro Jahr bauen zu können.

  3. Elektro-Pick-up: Neuer Tesla-Cybertruck-Prototyp gefilmt
    Elektro-Pick-up
    Neuer Tesla-Cybertruck-Prototyp gefilmt

    In einem Video wird ein neuer Cybertruck-Prototyp von Tesla im Detail gezeigt. Es stammt vermutlich aus der Gigafactory in Texas.

Du willst dich mit Golem.de beruflich verändern oder weiterbilden?
Zum Stellenmarkt
Zur Akademie
Zum Coaching
  • Schnäppchen, Rabatte und Top-Angebote
    Die besten Deals des Tages
    Daily Deals • RTX 3070 Ti 8GB 1.039€ • RX 6900XT 16 GB für 1.495€ • Acer Curved Gaming-Monitor 27" 259€ • RX 6800XT 16GB 1.229€ • Corsair 16GB DDR4-4000 111,21€ • 10% auf Gaming bei Ebay (u. a. Gigabyte 34" Curved UWQHD 144Hz 429,30€) • Razer Gaming-Stuhl 179,99€ [Werbung]
    •  /