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
