log4j 2.15 nicht wasserdicht: Apache veröffentlicht zweiten Notfall-Patch

Der Notfallpatch für die berüchtigte Schwachstelle in der Java-Bibliothek Log4j ist nicht narrensicher. Die Apache Software Foundation veröffentlicht eine neue Version, um die Schwachstelle ein für alle Mal zu beheben.

Eine Schwachstelle in einer äußerst beliebten Bibliothek für Java erschüttert die globale IT-Landschaft. Es wird geschätzt, dass die Bibliothek in den meisten Unternehmensumgebungen vorhanden ist.

Log4j wird hauptsächlich zum Loggen verwendet. Ereignisse in Anwendungen können mit Notizen registriert werden. Denken Sie an einen Ausdruck der Login-Daten nach einem Login-Versuch. Or, bei einer Webanwendung in Java, der Name des Browsers, mit dem ein Benutzer eine Verbindung herstellen möchte.

Die letzteren Beispiele sind üblich. In beiden Fällen, ein externer Benutzer beeinflusst das Log, das Log4j ausgibt. Es ist möglich, diesen Einfluss zu missbrauchen. Die Protokolle jeder Log4j-Version zwischen September 13, 2013 und Dezember 5, 2021 können Java-Anwendungen anweisen, den Code von einem Remote-Server auf einem lokalen Gerät auszuführen.

Seit 2013, Log4j hat eine API verarbeitet: JNDI, oder Java Naming and Directory Interface. Durch das Hinzufügen von JNDI kann eine Java-Anwendung Code von einem Remote-Server auf einem lokalen Gerät ausführen. Programmierer weisen an, indem sie eine einzelne Zeile mit Details zum Remote-Server in einer Anwendung hinzufügen.

Das Problem ist, dass nicht nur Programmierer die Regel zu Anwendungen hinzufügen können. Angenommen, Log4j protokolliert die Benutzernamen von Anmeldeversuchen. Wenn jemand die oben genannte Zeile in das Benutzernamensfeld eingibt, Log4j führt die Zeile aus und die Java-Anwendung interpretiert einen Befehl, um den Code auf dem angegebenen Server auszuführen. Das gleiche gilt für Fälle, in denen Log4j eine HTTPS-Anfrage protokolliert. Wenn Sie einen Browsernamen in die Zeile ändern, Log4j läuft die Linie, indirekt anweisen, Code wie gewünscht auszuführen.

Notfallpflaster kann auch unsicher sein

Im Dezember 9, die Schwachstelle kam im großen Stil ans Licht. Die Apache Software Foundation, Entwickler von Log4j, einen Notfall-Patch veröffentlicht (2.15) um die Schwachstelle zu beheben. Seit damals, Für Softwareanbieter war es oberste Priorität, die Version zu verarbeiten 2.15 und einen Patch für Organisationen bereitstellen.

jedoch, Sicherheitsorganisation LunaSec gibt an, dass der Patch nicht vollständig wasserdicht ist. Es bleibt weiterhin möglich, eine Einstellung anzupassen und protokollierte JNDI-Befehle ausführen zu lassen.

bitte beachten Sie: die entsprechende Einstellung muss manuell angepasst werden, so dass unveränderte Varianten von 2.15 sind in der Tat sicher. Dennoch, Luna Sec empfiehlt Lieferanten und Organisationen, auf Log4j zu aktualisieren 2.16. 2.16 wurde von der Apache Software Foundation als Reaktion auf LunaSec . veröffentlicht. Die neue Version entfernt die anfällige Einstellung vollständig, macht es unmöglich, die Bedingungen für Missbrauch zu schaffen.