Eine weitere Schwachstelle in Log4j 2. Die Probleme in Log4j betreffen 8 % der Maven-Pakete.

In der Log4j 2-Bibliothek wurde eine weitere Schwachstelle (CVE-2021-45105) entdeckt, die im Gegensatz zu den beiden vorherigen Problemen in die Kategorie der gefährlichen, jedoch nicht kritischen Schwachstellen fällt. Das neue Problem kann zu einem Dienstabbruch führen und äußert sich durch Endlosschleifen und Abstürze bei der Verarbeitung bestimmter Zeichenfolgen. Die Schwachstelle wurde in der vor wenigen Stunden veröffentlichten Version Log4j 2.17 behoben. Die Gefahr dieser Schwachstelle wird dadurch gemildert, dass sie nur auf Systemen mit Java 8 auftritt.

Betroffene Systeme sind solche, die bei der Definition des Ausgabeformats im Log kontextbezogene Abfragen (Context Lookup) verwenden, wie beispielsweise ${ctx:var}. In den Log4j-Versionen von 2.0-alpha1 bis 2.16.0 fehlte der Schutz vor unkontrollierter Rekursion, sodass ein Angreifer durch Manipulation des verwendeten Wertes bei der Substitution Endlosschleifen verursachen konnte, die zu einem Stacküberlauf und einem Prozessabbruch führten. Insbesondere trat das Problem bei der Substitution solcher Werte wie „${${::-${::-$${::-j}}}}“ auf.

Zusätzlich ist anzumerken, dass Forscher von Blumira eine Angriffsvariante auf anfällige Java-Anwendungen vorgeschlagen haben, die keine externen Netzwerkabfragen akzeptieren. Beispielsweise können Systeme von Entwicklern oder Benutzern von Java-Anwendungen auf diese Weise angegriffen werden. Der Grundgedanke besteht darin, dass Angriffe über JavaScript-Code, der beim Öffnen einer schädlichen Webseite in den Browsern der Benutzer ausgeführt wird, möglich sind, wenn auf dem System des Benutzers anfällige Java-Prozesse existieren, die Netzwerkverbindungen nur vom lokalen Host (localhost) akzeptieren oder RMI-Abfragen (Remote Method Invocation, Port 1099) verarbeiten. Für die Verbindung mit dem Netzwerkport der Java-Anwendung wird bei einem solchen Angriff die WebSocket-API verwendet, da im Gegensatz zu HTTP-Anfragen keine Same-Origin-Beschränkungen gelten (WebSocket kann außerdem zum Scannen von Netzwerkports auf dem lokalen Host eingesetzt werden, um vorhandene Netzwerk-Handler zu identifizieren).

Interessant sind auch die von Google veröffentlichten Ergebnisse zur Bewertung der Sicherheitsanfälligkeiten von Bibliotheken, die mit Log4j in Verbindung stehen. Laut Google betrifft das Problem 8 % aller Pakete im Maven Central Repository. Konkret sind 35.863 Java-Pakete betroffen, die direkte und indirekte Abhängigkeiten zu Log4j aufweisen. Dabei wird Log4j nur in 17 % der Fälle als direkte Erstlevel-Abhängigkeit verwendet, während in 83 % der betroffenen Pakete die Bindung über Zwischenschichten erfolgt, die von Log4j abhängen, d. h. über 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 Sicherheitsanfälligkeit sind bislang enttäuschend; eine Woche nach der Entdeckung der Schwachstelle wurde aus den 35.863 betroffenen Paketen bisher nur in 4.620, also in 13 %, das Problem behoben.

In der Zwischenzeit hat die US-Behörde für Cybersicherheit und Infrastruktur-Schutz eine dringende Richtlinie veröffentlicht, die föderale Behörden verpflichtet, die Informationssysteme zu identifizieren, die von der Log4j-Sicherheitsanfälligkeit betroffen sind, und bis zum 23. Dezember die Updates zu installieren, die das Problem beheben. Bis zum 28. Dezember sind die Organisationen verpflichtet, über die durchgeführten Arbeiten Bericht zu erstatten. Um die Identifizierung der betroffenen Systeme zu erleichtern, wurde eine Liste von Produkten erstellt, in denen die Sicherheitsanfälligkeit bestätigt wurde (die Liste umfasst über 23.000 Anwendungen).

Quelle: opennet.ru