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.

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

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


demon driver 18. Dez 2021

Überschriften und zugehörige Unterzeilen soll man sich also erst aus dem Kontext des...

andy848484 15. Dez 2021

Logback hat auch eine 1.2.8 veröffentlicht und darin sämtlichen JNDI Code entfernt...

minnime 15. Dez 2021

Kann man denn die Klasse JndiLookup.class einfach so entfernen? Meistens ist der Code...



Aktuell auf der Startseite von Golem.de
Entwickler
ChatGPT könnte Google-Job mit 183.000 Dollar Gehalt kriegen

Google hat ChatGPT mit Fragen aus seinem Entwickler-Bewerbungsgespräch gefüttert. Die KI könne demnach eine Einsteigerposition erhalten.

Entwickler: ChatGPT könnte Google-Job mit 183.000 Dollar Gehalt kriegen
Artikel
  1. Politische Ansichten auf Google Drive: Letzte Generation mit Datenschutz-Super-GAU
    Politische Ansichten auf Google Drive
    Letzte Generation mit Datenschutz-Super-GAU

    Die Aktivisten der Letzten Generation haben Daten von Unterstützern mitsamt politischer Meinung und Gefängnisbereitschaft ungeschützt auf Google Drive gelagert.

  2. Windkraft-Ausbauplan: Scholz will vier bis fünf neue Windräder pro Tag
    Windkraft-Ausbauplan
    Scholz will vier bis fünf neue Windräder pro Tag

    Die Energiewende in Deutschland soll durch einen massiven Ausbau der Windkraft-Anlagen vorangetrieben werden. Bundeskanzler Scholz will Tempo machen.

  3. Telekom-Internet-Booster: Hybridzugang der Telekom mit 5G ist verfügbar
    Telekom-Internet-Booster
    Hybridzugang der Telekom mit 5G ist verfügbar

    Die 5G-Antenne der Telekom hängt an einem zehn Meter langen Flachbandkabel. Die zugesagte Datenrate reicht bis 300 MBit/s im Download.

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 • Logitech G915 Lightspeed 219,89€ • ASUS ROG Strix Scope Deluxe 107,89€ • Gigabyte B650 Gaming X AX 185,99€ • Alternate Weekend Sale • MindStar: be quiet! Dark Rock 4 49€, Fastro MS200 2TB 95€ • Mindfactory DAMN-Deals: Grakas & CPUS u. a. AMD Ryzen 7 5700X 175€ • PCGH Cyber Week [Werbung]
    •  /