{"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 Sicherheitsanf\u00e4lligkeit in Log4j 2. 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 festgestellt (CVE-2021-45105), die im Gegensatz zu den beiden vorherigen Problemen als gef\u00e4hrlich, aber nicht kritisch eingestuft wird. Das neue Problem erm\u00f6glicht einen Denial-of-Service-Angriff und \u00e4u\u00dfert sich in Form von Endlosschleifen und Abst\u00fcrzen beim Verarbeiten bestimmter Zeichenfolgen. Die Schwachstelle wurde in der vor wenigen Stunden ver\u00f6ffentlichten Version Log4j 2.17 behoben. Die Gef\u00e4hrlichkeit der Schwachstelle wird dadurch gemildert, dass das Problem nur auf Systemen mit Java 8 auftritt. <\/p>\n
Systeme, die kontextbezogene Abfragen (Context Lookup) wie ${ctx:var} zur Bestimmung des Log-Ausgabeformats verwenden, sind anf\u00e4llig f\u00fcr Schwachstellen. In Log4j-Versionen von 2.0-alpha1 bis einschlie\u00dflich 2.16.0 fehlte der Schutz vor unkontrollierbarer Rekursion, was es einem Angreifer erm\u00f6glichte, durch Manipulation des Werts, der bei der Substitution verwendet wird, eine Endlosschleife auszul\u00f6sen, die zu einem Stackoverflow und einem Absturz des Prozesses f\u00fchrte. Insbesondere trat das Problem bei der Substitution solcher Werte wie «${${::-${::-$${::-j}}}}» auf. <\/p>\n
Zus\u00e4tzlich kann erw\u00e4hnt werden, dass Forscher von Blumira einen Angriff auf anf\u00e4llige Java-Anwendungen vorgeschlagen haben, die keine externen Netzwerk-Anfragen annehmen, beispielsweise k\u00f6nnen 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\u00fchrt werden kann, der beim \u00d6ffnen einer sch\u00e4dlichen Seite im Browser des Nutzers ausgef\u00fchrt 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\u00e4nkungen gelten (WebSocket kann auch verwendet werden, um Netzwerkanfragen auf dem lokalen Host zu scannen, um vorhandene Netzwerk-Handler zu identifizieren).
<\/center> <\/p>\n
Auch die von Google ver\u00f6ffentlichten Ergebnisse zur Bewertung der Schwachstellen in Bibliotheken, die von Log4j abh\u00e4ngen, sind von Interesse. Laut Google betrifft das Problem 8 % aller Pakete im Maven Central Repository. In total sind 35863 Java-Pakete, die direkt oder indirekt von Log4j abh\u00e4ngen, anf\u00e4llig f\u00fcr Schwachstellen. Dabei wird Log4j nur in 17 % der F\u00e4lle als direkte erste Ebene verwendet, w\u00e4hrend 83 % der betroffenen Pakete \u00fcber abh\u00e4ngige Zwischenpakete, d.h. Abh\u00e4ngigkeiten h\u00f6herer Ordnung, an Log4j gebunden sind (21 % \u2014 zweite Ebene, 12 % \u2014 dritte, 14 % \u2014 vierte, 26 % \u2014 f\u00fcnfte, 6 % \u2014 sechste). Die Tempo der Behebung der Schwachstelle lassen bisher zu w\u00fcnschen \u00fcbrig; eine Woche nach Bekanntwerden der L\u00fccke wurde das Problem bisher nur in 4620 von 35863 identifizierten Paketen behoben, d.h. in 13 %.
<\/center> <\/p>\n
In der Zwischenzeit hat die US-Agentur f\u00fcr Cybersicherheit und Infrastruktur Sicherheit eine Notfallrichtlinie ver\u00f6ffentlicht, die Bundesbeh\u00f6rden verpflichtet, die betroffenen Informationssysteme, die verwundbar gegen\u00fcber Log4j sind, zu identifizieren und bis zum 23. Dezember Updates zu installieren, die das Problem beheben. Bis zum 28. Dezember m\u00fcssen die Organisationen \u00fcber die durchgef\u00fchrten 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 \u00fcber 23000 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