Skip to main content

Log4j 2.17.1 behebt CVE-2021-44832: Remote Code Execution (aber nicht so schlimm, wie es klingt)

blog feature log4j vulnerability blue

29. Dezember 2021

0 Min. Lesezeit

Wie bereits vorhergesagt, wurde am 28. Dezember 2021 gegen 19:35 Uhr GMT eine weitere Sicherheitslücke in der Logging-Bibliothek Log4j als CVE-2021-44832 veröffentlicht.

Die neue Sicherheitslücke CVE-2021-44832 betrifft Versionen bis einschließlich 2.17.0, die zuvor als fehlerfrei galt. Die Art dieser Sicherheitslücke ähnelt CVE-2021-4104, die den 1.x-Zweig von Log4j betraf.

Die Auswirkungen von CVE-2021-44832

Wenn Sie schnell auf die neueste Version von Log4j mit Fehlerbehebung aktualisieren können, sollten Sie das tun. Allerdings möchten wir darauf hinweisen, dass diese spezielle Sicherheitslücke CVE-2021-44832 mit einem mittleren CVSS-Wert von 6,6 eingestuft wurde und für eine erfolgreiche Ausnutzung durch Angreifer deutlich erhöhte Voraussetzungen erfordert.

CVE-2021-44832 stuft Log4j 2.17.0 (und ältere Versionen) als anfällig für Codeausführung ein, wenn ein Angreifer den Inhalt der Logging-Konfigurationsdatei kontrollieren und ändern kann, sodass diese auf eine Remote-URI-Datenquelle verweist, über die beliebiger Java-Code geladen wird.

Die Fehlerbehebung in Version 2.17.1, die auch auf ältere JVM-kompatible Versionen der Bibliothek zurückportiert wurde, entschärft die Sicherheitslücke, indem sie die JNDI-Datenquelle in der Konfigurationsdatei auf die Verwendung des Java-Protokolls beschränkt und sämtliche Remote-Netzwerkaufrufe unterbindet.

Sofortmaßnahmen zur Behebung von CVE-2021-44832

Das Log4j-Team hat Fehlerbehebungen für diese Sicherheitslücke veröffentlicht:

  • Wenn Sie Java 8 oder höher verwenden: aktualisieren Sie auf Log4j 2.17.1

  • Wenn Sie den Zweig 2.12.x für Java 7 verwenden: aktualisieren Sie auf Log4j 2.12.4

  • Wenn Sie den Zweig 2.3.x für Java 6 verwenden: aktualisieren Sie auf Log4j 2.3.2

Eine Flut vorzeitig durchgesickerter Log4j-Sicherheitslücken

Die Offenlegung dieser Sicherheitslücke steht im Zusammenhang mit einem zunehmend besorgniserregenden Trend unverantwortlicher Offenlegungen rund um Log4j: Sicherheitsforscher haben Details zu gemeldeten Sicherheitslücken veröffentlicht, bevor die Maintainer ausreichend Zeit hatten, das Problem ordnungsgemäß zu beheben und neue Versionen bereitzustellen.

Dieses problematische Phänomen begann mit der ursprünglichen Log4j-RCE: Forscher veröffentlichten Details und sogar einen Proof of Concept der Sicherheitslücke auf Twitter und GitHub – Stunden vor der offiziellen Offenlegung (siehe unsere Zeitleiste). Auch die Existenz dieser Sicherheitslücke wurde mehrere Stunden vor der offiziellen Veröffentlichung von einem Sicherheitsforscher, der sich die Entdeckung zuschrieb, auf Twitter bekannt gemacht.

In beiden Fällen scheint das Durchsickern von Informationen – vermutlich ohne böswillige Absicht – zu einer überstürzten Veröffentlichung durch Apache geführt zu haben. Dadurch könnten weitere Sicherheitslücken und Fehler in der neuen Version entstehen. Außerdem ist anzunehmen, dass Apache sich unter anderen Umständen nicht für eine Veröffentlichung zu einer Jahreszeit entschieden hätte, in der viele Unternehmen Betriebsferien haben und Probleme deshalb bei Bedarf weniger schnell bewerten und beheben können.

Die Sicherheit von Open Source ist für die Welt insgesamt zunehmend wichtig, und verantwortungsvolle Offenlegungspraktiken sind ein Grundpfeiler für die kontinuierliche Sicherheit unserer Community. Wir hoffen, dass zukünftige Offenlegungen zu Log4j oder anderen Open-Source-Paketen verantwortungsvoller gehandhabt werden.

Wie immer setzen wir bei Snyk uns für unser Programm zur verantwortungsvollen Offenlegung ein. Gleichzeitig behalten wir potenzielle neue Bedrohungen im Blick und stellen unseren Nutzerinnen und Nutzern sowie der Open-Source-Community schnell umsetzbare Informationen bereit.