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:

Oracle Java wieder mit kostenfreiem JDK

Veröffentlicht am von
Antworten

Seit Oracle die das Java Java Development Kit vor einigen Jahren in eine kostenpflichtige Subscription verwandelt hat, gab es diverse kontroverse Diskussionen darüber. Im Gegensatz zum wahrscheinlich von Oracle erwarteten Effekt, dass jetzt alle Java-Nutzer Subscriptions abschließen (und bezahlen) würden, war offenbar eher das Gegenteil der Fall: viele User wendeten sich von Oracle Java ab und kostenlosen OpenSource-Alternativen zu. Doch nun gibt es neue Nachrichten:

Weiterlesen →

SQL Macros: neu in Oracle 21c… und in Oracle 19c!

Veröffentlicht am von

Oracle 21c ist in diversen Cloud-Umgebungen bereits verfügbar. Die on-premises-Version wird für das erste Halbjahr 2021 erwartet – also schon recht bald. Neu und sehr interessant sind SQL Macros.

SQL und PL/SQL sind zwei sehr unterschiedliche Sprachen mit unterschiedlichen Konzepten. Oracle hat grundsätzlich Möglichkeiten eingebaut, die beiden Sprachen zu verbinden. SQLs können in PL/SQL-Code ausgeführt werden und PL/SQL-Funktionen können in SQLs verwendet werden: in der SELECT-Liste in in WHERE-Bedingungen.

Weiterlesen →

DPLOAD-Patch für 19.10 – aber (noch?) nicht für Windows

Veröffentlicht am von
Antworten

Oracle hat vor einigen Tagen einen Merger-Patch für das RU 19.10 herausgebracht. Dieser soll bekannte Performance-Probleme bei der Verwendung von dpload.sql (im Zusammenhang mit datapatch) beheben. Ob dies tatsächlich der Fall ist, kann man leider unter Windows nicht herausfinden – denn obwohl der Patch Nr. 32551008 als „generic“, also für alle Plattformen, deklariert ist, funktioniert die Installation nicht unter Windows.

Weiterlesen →

Neues vom SYSAUX-Tablespace…

Veröffentlicht am von
Antworten

Der SYSAUX-Tablespace wurde von Oracle in der Version 10g eingeführt. Hier werden diverse sog. „Auxiliary“ Objekte gespeichert, die Oracle-eigenen Schemata zuzuordnen sind. Die Menge der enthaltenen Objekte sowie der Platzbedarf hängen u.a. von der Anzahl der in der Datenbank installierten Komponenten ab. In der Regel sind diese unkritisch – es kann aber vorkommen, dass der Platzbedarf im SYSAUX-Tablespaces plötzlich stark ansteigt, ohne dass etwas neues installiert oder überhaupt irgendetwas getan wurde.

Weiterlesen →

Der ODA-Patch 19.10 ist da!

Veröffentlicht am von
Antworten

Am 08. März wurde das neueste ODA-Software-Release 19.10 veröffentlicht. Warum ist dies ein Anlass zur Freude? Schließlich gibt es diese Patches für die Database Appliance, die kleine Schwester der Exadata, mehrmals pro Jahr.

Nun – in dieser sind einige Neuerungen enthalten, die die Verwendungs- und Konfigurationsmöglichkeiten mehr als sonst bei Patchen üblich verändern…

Weiterlesen →

Upgrade-Problemchen in 19c unter Windows

Veröffentlicht am von
Antworten

In meiner nunmehr 20-jährigen Erfahrung mit Oracle ist es schon eine Tradition, dass man unter Windows, naja, sagen wir mal, ein bisschen das „Schmuddelkind“ ist oder sich zumindest so von Oracle behandelt fühlt. Das beginnt bei der Dokumentation (inzwischen werden hier zumindest die Variablen nicht mehr mit $ bezeichnet…), geht weiter bei (nicht vorhandenen) Skript-Beispielen und zieht sich bis zum Patch- und Upgrade-Management.

Leider scheint sich dies auch in den neueren Versionen fortzusetzen. Aktuell gibt es zwei Bugs sowohl beim Upgrade auf die Versionen 19.4.0.0 / 19.5.0.0 sowie 19.6.0.0, …

Weiterlesen →

Mögliche Probleme mit One-Off Patches in 19c aufgrund falscher Patch-Metadaten

Veröffentlicht am von

In der Oracle-Version 19 mit installierten DB-RUs 19.3, 19.4 oder dem DB-RUR 19.3.1 sind möglicherweise die Patch-Metadaten korrupt und / oder unvollständig.

Dies fällt beim Versuch auf, einen One-Off Patch zu installieren – hier erscheint dann die Fehlermeldung:

„Skip patch <bug#> from list of patches to apply: This patch is not needed.”

Dies wird im MOS Dokument Potential Impact to Database 19c One-off patches Due to Incorrect Patch Level Metadata (Doc ID 2575299.1) beschrieben.

Bei einem der o.g. Software-Ständen sollte laut dem MOS-Artikel ein Skript (chech_patch_level.sh) heruntergeladen und aus dem betreffenden ORACLE_HOME heraus ausgeführt werden, um festzustellen, ob das Problem in der aktuellen Umgebung existiert. Idealerweise ist der Output:

************************************************************
No action is required at this time
*************************************************************

Ansonsten muss / müssen der / die im Output genannte Patch(es) zurückgerollt, erneut heruntergeladen und neu installiert werden.