In der Log4j 2-Bibliothek wurde eine weitere Schwachstelle festgestellt (CVE-2021-45105), die im Gegensatz zu den beiden vorherigen Problemen als gefährlich, aber nicht kritisch eingestuft wird. Das neue Problem ermöglicht einen Denial-of-Service-Angriff und äußert sich in Form von Endlosschleifen und Abstürzen beim Verarbeiten bestimmter Zeichenfolgen. Die Schwachstelle wurde in der vor wenigen Stunden veröffentlichten Version Log4j 2.17 behoben. Die Gefährlichkeit der Schwachstelle wird dadurch gemildert, dass das Problem nur auf Systemen mit Java 8 auftritt.
Betroffen sind Systeme, die kontextuelle Abfragen (Context Lookup) zur Bestimmung des Ausgabeformats in Logs verwenden, wie ${ctx:var}. In den Versionen von Log4j, beginnend mit 2.0-alpha1 bis hin zu 2.16.0, fehlte der Schutz gegen unkontrollierte Rekursion, was es einem Angreifer ermöglichte, durch Manipulation des Wertes, der für die Ersetzung verwendet wird, eine Endlosschleife auszulösen, die zu einem Stackoverflow und einem Absturz des Prozesses führte. Insbesondere trat das Problem bei der Ersetzung solcher Werte wie "${${::-${::-$${::-j}}}}" auf.
Zusätzlich kann erwähnt werden, dass Forscher von Blumira einen Angriff auf anfällige Java-Anwendungen vorgeschlagen haben, die keine externen Netzwerk-Anfragen annehmen, beispielsweise können Systeme von Entwicklern oder Nutzern von Java-Anwendungen auf diese Weise angegriffen werden. Der Kern der Methode besteht darin, dass, wenn auf dem System des Nutzers verwundbare Java-Prozesse vorhanden sind, die nur Netzwerkverbindungen vom lokalen Host (localhost) akzeptieren oder RMI-Anfragen (Remote Method Invocation, Port 1099) verarbeiten, der Angriff durch JavaScript-Code durchgeführt werden kann, der beim Öffnen einer schädlichen Seite im Browser des Nutzers ausgeführt wird. Um eine Verbindung zum Netzwerkport der Java-Anwendung bei einem solchen Angriff herzustellen, wird die WebSocket-API verwendet, bei der im Gegensatz zu HTTP-Anfragen keine same-origin-Einschränkungen gelten (WebSocket kann auch verwendet werden, um Netzwerkanfragen auf dem lokalen Host zu scannen, um vorhandene Netzwerk-Handler zu identifizieren).
Auch von Interesse sind die von Google veröffentlichten Ergebnisse zur Bewertung der Verwundbarkeit von Bibliotheken, die Abhängigkeiten von Log4j aufweisen. Laut Google betrifft das Problem 8 % aller Pakete im Maven Central Repository. Insbesondere waren 35863 Java-Pakete, die mit Log4j sowohl direkt als auch indirekt verbunden sind, von den Sicherheitslücken betroffen. Dabei wird Log4j nur in 17 % der Fälle als direkte Abhängigkeit erster Ebene verwendet, während in 83 % der betroffenen Pakete die Bindung über Zwischenpakete erfolgt, die von Log4j abhängen, d.h. Abhängigkeiten zweiter und höherer Ebene (21 % - zweiter Ebene, 12 % - dritter, 14 % - vierter, 26 % - fünfter, 6 % - sechster). Die Fortschritte bei der Behebung der Sicherheitslücken lassen bisher zu wünschen übrig: Eine Woche nach Entdeckung der Sicherheitslücke sind von den 35863 entdeckten Paketen nur 4620, also 13 %, behoben.
In der Zwischenzeit hat die US-Agentur für Cybersicherheit und Infrastruktur Sicherheit eine Notfallrichtlinie veröffentlicht, die Bundesbehörden verpflichtet, die betroffenen Informationssysteme, die verwundbar gegenüber Log4j sind, zu identifizieren und bis zum 23. Dezember Updates zu installieren, die das Problem beheben. Bis zum 28. Dezember müssen die Organisationen über die durchgeführten Arbeiten Bericht erstatten. Um die Identifizierung problematischer Systeme zu erleichtern, wurde eine Liste von Produkten erstellt, bei denen die Verwundbarkeit nachgewiesen wurde (die Liste umfasst über 23000 Anwendungen).
Quelle: opennet.ru
