{"id":102661,"date":"2021-12-19T03:36:43","date_gmt":"2021-12-19T01:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov"},"modified":"2021-12-19T03:36:43","modified_gmt":"2021-12-19T01:36:45","slug":"eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/eshhyo-odna-uyazvimost-v-log4j-2-problemy-v-log4j-zatragivayut-8-maven-paketov","title":{"rendered":"Eine weitere Schwachstelle in Log4j 2. Die Probleme in Log4j betreffen 8 % der Maven-Pakete.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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\u00e4hrlichen, jedoch nicht kritischen Schwachstellen f\u00e4llt. Das neue Problem kann zu einem Dienstabbruch f\u00fchren und \u00e4u\u00dfert sich durch Endlosschleifen und Abst\u00fcrze bei der Verarbeitung bestimmter Zeichenfolgen. Die Schwachstelle wurde in der vor wenigen Stunden ver\u00f6ffentlichten Version Log4j 2.17 behoben. Die Gefahr dieser Schwachstelle wird dadurch gemildert, dass sie nur auf Systemen mit Java 8 auftritt. <\/p>\n
Systeme, die kontextabh\u00e4ngige Abfragen (Context Lookup) zur Bestimmung des Log-Ausgabeformats verwenden, wie ${ctx:var}, sind anf\u00e4llig f\u00fcr Schwachstellen. In den Log4j-Versionen von 2.0-alpha1 bis 2.16.0 fehlte ein Schutz gegen unkontrollierte Rekursion, was es einem Angreifer erm\u00f6glichte, durch Manipulation des zur Substitution verwendeten Werts eine Endlosschleife auszul\u00f6sen, die zu einem Stackoverflow und zum Absturz des Prozesses f\u00fchrte. Besonders problematisch war dies bei der Substitution solcher Werte wie \u00ab${${::-${::-$${::-j}}}}\u00bb. <\/p>\n
Zus\u00e4tzlich ist anzumerken, dass Forscher von Blumira eine Angriffsvariante auf anf\u00e4llige Java-Anwendungen vorgeschlagen haben, die keine externen Netzwerkabfragen akzeptieren. Beispielsweise k\u00f6nnen Systeme von Entwicklern oder Benutzern von Java-Anwendungen auf diese Weise angegriffen werden. Der Grundgedanke besteht darin, dass Angriffe \u00fcber JavaScript-Code, der beim \u00d6ffnen einer sch\u00e4dlichen Webseite in den Browsern der Benutzer ausgef\u00fchrt wird, m\u00f6glich sind, wenn auf dem System des Benutzers anf\u00e4llige Java-Prozesse existieren, die Netzwerkverbindungen nur vom lokalen Host (localhost) akzeptieren oder RMI-Abfragen (Remote Method Invocation, Port 1099) verarbeiten. F\u00fcr 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\u00e4nkungen gelten (WebSocket kann au\u00dferdem zum Scannen von Netzwerkports auf dem lokalen Host eingesetzt werden, um vorhandene Netzwerk-Handler zu identifizieren).
<\/center> <\/p>\n
Auch die von Google ver\u00f6ffentlichten Ergebnisse zur Bewertung der Verwundbarkeit von Bibliotheken, die Abh\u00e4ngigkeiten zu Log4j aufweisen, sind von Interesse. Laut Google betrifft das Problem 8 % aller Pakete im Maven Central-Repository. Insbesondere sind 35.863 Java-Pakete, die mit Log4j sowohl direkt als auch indirekt verbunden sind, von dieser Verwundbarkeit betroffen. Dabei wird Log4j in nur 17 % der F\u00e4lle als direkte erste Ebene-Abh\u00e4ngigkeit verwendet, w\u00e4hrend in 83 % der betroffenen Pakete die Bindung \u00fcber Zwischenpakete erfolgt, die von Log4j abh\u00e4ngen, d. h. auf zweiter und h\u00f6herer Ebene (21 % auf der zweiten Ebene, 12 % auf der dritten, 14 % auf der vierten, 26 % auf der f\u00fcnften und 6 % auf der sechsten Ebene). Die Schnelligkeit, mit der die Sicherheitsl\u00fccke behoben wird, l\u00e4sst bislang zu w\u00fcnschen \u00fcbrig; eine Woche nach Entdeckung der Schwachstelle wurde das Problem bisher nur in 4.620 von 35.863 identifizierten Paketen, also in 13 %, behoben.
<\/center> <\/p>\n
In der Zwischenzeit hat die US-Beh\u00f6rde f\u00fcr Cybersicherheit und Infrastruktur-Schutz eine dringende Richtlinie ver\u00f6ffentlicht, die f\u00f6derale Beh\u00f6rden verpflichtet, die Informationssysteme zu identifizieren, die von der Log4j-Sicherheitsanf\u00e4lligkeit betroffen sind, und bis zum 23. Dezember die Updates zu installieren, die das Problem beheben. Bis zum 28. Dezember sind die Organisationen verpflichtet, \u00fcber die durchgef\u00fchrten Arbeiten Bericht zu erstatten. Um die Identifizierung der betroffenen Systeme zu erleichtern, wurde eine Liste von Produkten erstellt, in denen die Sicherheitsanf\u00e4lligkeit best\u00e4tigt wurde (die Liste umfasst \u00fcber 23.000 Anwendungen). \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Eine](\"\/wp-content\/uploads\/2021\/12\/811931e8c3ae3f3f3c2e81db361034e6.jpg\")
<\/center> <\/p>\n![\"Eine](\"\/wp-content\/uploads\/2021\/12\/1e61b09923c7e055fa635545f1b3de6b.jpg\")
<\/center> <\/p>\n