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

28. 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.

Weiterlesen

illustration hero ai
Blog

PHP behebt zwei kritische unauthentifizierte RCE-Schwachstellen (CVE-2026-109618, CVE-2026-109619): Jetzt aktualisieren

Zwei kritische Sicherheitslücken im Request-Lebenszyklus von PHP können unauthentifizierte Remote Code Execution ermöglichen. Aktualisieren Sie auf eine korrigierte Version oder installieren Sie für ältere Versionen einen Backport des Anbieters.

blog feature ai lilac
Blog

Mit agentischer Behebung Ihren Schwachstellen-Backlog in Pull Requests verwandeln

Der Evo Remediation Agent ist jetzt in der öffentlichen Vorschau verfügbar und erweitert Evo Agentic AppSec um die automatisierte Auflösung von Abhängigkeiten. AppSec-Teams können jetzt kontinuierliche Behebungskampagnen durchführen

AI Background min crop
Blog

KI ruft alle Risiken auf den Plan, die Sie akzeptiert haben: Sieben Erkenntnisse aus dem AI Security Panel: Unfiltered

KI macht Angriffe günstiger und schneller und legt Risiken offen, die Unternehmen bereits tragen. Vier Sicherheitsverantwortliche erklären, warum Abwehr in Maschinengeschwindigkeit und schnellere Behebung jetzt unverzichtbar sind.