Schlagwort-Archive: log4j

Oracle Produkte und die log4j-Sicherheitslücke (CVE-2021-44228 „Log4Shell“, CVE-2021-45046 und CVE-2021-45105)

Veröffentlicht am von

Letzte Änderung dieses Blog Posts: 13.1.2022 8:45

Die Sicherheitslücken CVE-2021-44228 „Log4Shell“, CVE-2021-45046, CVE-2021-45105 sowie CVE-2021-44832 betreffen die Java-Komponente log4j der Apache Foundation.

Der Patch für die erste Sicherheitslücke CVE-2021-44228 in Form der log4j-Version 2.15 war nicht vollständig, so dass am 14.12.2021 CVE-2021-45046 für diese Version veröffentlicht wurde. Alle Patches, die log4j 2.15 enthalten, sind somit hinfällig. Dies gilt nun auch für die Patches, die log4j 2.16 enthalten, da am 19.12.2021 mit CVE-2021-45105 eine weitere Lücke hinzugekommen ist, die DOS-Angriffe auf ungepatchte Installationen ermöglicht. Diese Lücke ist mit log4j 2.17 beseitigt. Die aktuellste Version für log4j ist 2.17.1 und enthält zusätzlich Fixes bzgl. CVE-2021-44832.

Die Log4Shell Sicherheitslücke betrifft sehr viele Oracle Produkte. Das ursprüngliche zentrale Dokment bei Oracle (Impact of December 2021 Apache Log4j Vulnerabilities on Oracle Products and Services (CVE-2021-44228, CVE-2021-45046) (Doc ID 2827611.1)) verweist nun auf zwei Unterdokumente, je eines für die Oracle Cloud (Impact of December 2021 Apache Log4j Vulnerabilities on Oracle cloud environments (CVE-2021-44228, CVE-2021-45046) (Doc ID 2830129.1)) und für On-Premises-Produkte (Impact of December 2021 Apache Log4j Vulnerabilities on Oracle on-premises products (CVE-2021-44228, CVE-2021-45046) (Doc ID 2830143.1)). Hier gibt es einen Überblick über alle vorhandenen und geplanten Patches, sowie über Produkte, die keinen Patch benötigen. In diesem Blog Post fassen wir zusammen, was wir über die wichtigsten (On-Premises-) Produkte wissen und welche Vorgehensweise wir empfehlen. Sobald wir relevante neue Informationen bekommen werden wir diese hier einfließen lassen.

Weiterlesen →

Monitoring Module ist nicht von kritischer log4j-Sicherheitslücke (CVE-2021-44228 „Log4Shell“) betroffen

Veröffentlicht am von

Das Monitoring Module (HLMM) verwendet als Basis Spring Boot, welches im Standard wiederum kein log4j2 verwendet. In den ausgelieferten Libraries (exemplarisch für die Web-Application des aktuellen Releases) findet man auf dem Monitoring-Server einige JAR-Dateien, die auf log4j in einer der betroffenen Versionen hindeuten:

# locate log4j | grep jar$ | grep webapp
/var/lib/hlmon/webapp/lib/2.48.0_3106/WEB-INF/lib/log4j-api-2.14.1.jar
/var/lib/hlmon/webapp/lib/2.48.0_3106/WEB-INF/lib/log4j-over-slf4j-1.7.32.jar
/var/lib/hlmon/webapp/lib/2.48.0_3106/WEB-INF/lib/log4j-to-slf4j-2.14.1.jar

Hier fehlt allerdings explizit die Datei beginnend „log4j-core“, welche von den aktuellen Sicherheitsproblemen betroffen ist. Spring Boot und damit auch HLMM enthält zwar die Log4J-API, nutzt im Standard intern allerdings SLF4J/Logback.

Weiterführende Informationen dazu finden Sie auch unter dem folgenden Link:
https://github.com/spring-projects/spring-boot/issues/28958

Spring Boot does not use log4j2 by default and those of you who are opting-in for log4j2 can update to a version that fixes the problem.

Quelle

Im Kern heißt dies also: HLMM ist von dem Problem nicht betroffen und es sind keine außerplanmäßigen Patches erforderlich.

Update 15.12.2021: HLMM ist auch nicht von der Sicherheitslücke CVE-2021-45046 betroffen.

Update 18.12.2021: HLMM ist auch nicht von der Sicherheitslücke CVE-2021-45105 betroffen.

Weitere Informationen zu der Sicherheitslücke: