In der Log4j 2-Bibliothek wurde eine weitere Schwachstelle identifiziert (CVE-2021-45105), die im Gegensatz zu den beiden vorherigen Problemen als gefährlich, aber nicht kritisch eingestuft wird. Das neue Problem ermöglicht es Ihnen, einen Denial-of-Service auszulösen und äußert sich in Form von Schleifen und Abstürzen bei der Verarbeitung bestimmter Zeilen. Die Schwachstelle wurde in der vor einigen Stunden veröffentlichten Version Log4j 2.17 behoben. Die Gefährlichkeit der Schwachstelle wird dadurch gemindert, dass das Problem nur auf Systemen mit Java 8 auftritt.
Die Schwachstelle betrifft Systeme, die kontextbezogene Abfragen (Context Lookup), wie z. B. ${ctx:var}, verwenden, um das Protokollausgabeformat zu bestimmen. Den Log4j-Versionen von 2.0-alpha1 bis 2.16.0 fehlte der Schutz vor unkontrollierter Rekursion, was es einem Angreifer ermöglichte, den bei der Ersetzung verwendeten Wert zu manipulieren, um eine Schleife auszulösen, was zu einer Erschöpfung des Stapelspeichers und einem Absturz führte. Das Problem trat insbesondere beim Ersetzen von Werten wie „${${::-${::-$${::-j}}}}“ auf.
Darüber hinaus ist festzuhalten, dass Forscher von Blumira eine Möglichkeit vorgeschlagen haben, anfällige Java-Anwendungen anzugreifen, die keine externen Netzwerkanfragen akzeptieren; auf diese Weise können beispielsweise die Systeme von Entwicklern oder Benutzern von Java-Anwendungen angegriffen werden. Der Kern der Methode besteht darin, dass der Angriff durch ausgeführten JavaScript-Code ausgeführt werden kann, wenn auf dem System des Benutzers anfällige Java-Prozesse vorhanden sind, die Netzwerkverbindungen nur vom lokalen Host akzeptieren oder RMI-Anfragen verarbeiten (Remote Method Invocation, Port 1099). wenn Benutzer eine schädliche Seite in ihrem Browser öffnen. Um bei einem solchen Angriff eine Verbindung zum Netzwerkport einer Java-Anwendung herzustellen, wird die WebSocket-API verwendet, auf die im Gegensatz zu HTTP-Anfragen keine Same-Origin-Einschränkungen angewendet werden (WebSocket kann auch zum Scannen von Netzwerkports auf der lokalen Ebene verwendet werden). Host, um verfügbare Netzwerkhandler zu ermitteln).
Interessant sind auch die von Google veröffentlichten Ergebnisse zur Bewertung der Anfälligkeit von Bibliotheken im Zusammenhang mit Log4j-Abhängigkeiten. Laut Google betrifft das Problem 8 % aller Pakete im Maven Central Repository. Insbesondere 35863 Java-Pakete, die über direkte und indirekte Abhängigkeiten mit Log4j verbunden sind, waren Schwachstellen ausgesetzt. Gleichzeitig wird Log4j nur in 17 % der Fälle als direkte Abhängigkeit der ersten Ebene verwendet, und in 83 % der betroffenen Pakete erfolgt die Bindung über Zwischenpakete, die von Log4j abhängen, d. h. Süchte der zweiten und höheren Stufe (21 % – zweite Stufe, 12 % – dritte, 14 % – vierte, 26 % – fünfte, 6 % – sechste). Das Tempo der Behebung der Schwachstelle lässt noch zu wünschen übrig; eine Woche nach der Entdeckung der Schwachstelle wurde das Problem von 35863 identifizierten Paketen bisher nur in 4620 behoben, d. h. bei 13 %.
In der Zwischenzeit hat die US-Behörde für Cybersicherheit und Infrastrukturschutz eine Dringlichkeitsrichtlinie erlassen, die die Bundesbehörden dazu auffordert, die von der Log4j-Schwachstelle betroffenen Informationssysteme zu identifizieren und bis zum 23. Dezember Updates zu installieren, die das Problem blockieren. Bis zum 28. Dezember müssen Organisationen über ihre Arbeit berichten. Um die Identifizierung problematischer Systeme zu vereinfachen, wurde eine Liste von Produkten erstellt, bei denen bestätigt wurde, dass sie Schwachstellen aufweisen (die Liste umfasst mehr als 23 Anwendungen).
Source: opennet.ru