DOAG Konferenz + Ausstellung im November 2023

Vom 21. bis 24. November in Nürnberg im Nürnberg Convention Center (NCC). Wie in den Jahren zuvor waren wir auch dieses Jahr an der DOAG Konferenz + Ausstellung mit einem Vortrag vertreten. Der Vortrag vom 23.11. „Auf zur Oracle Database 23c: New Features, Upgrade-Szenarien, erste Erfahrungen“ von Herrn Lenz steht nun als PDF zum Download bereit

Neues vom SYSAUX-Tablespace Vol. II

Vor einiger Zeit hatten wir ja schon einmal über die Freuden der Objektverwaltung im SYSAUX-Tablespace berichtet (s. HIER).

Heute aus aktuellem Anlass eine kleine Geschichte für all jene, die sich auch darüber wundern, warum Abfragen gegen Data Dictionary Views, hier insbesondere diejenigen, die den Job Scheduler betreffen, immer so lange dauern. Es könnte evtl. an diesem Umstand liegen:

Weiterlesen

Neue Aufräum-Routine für inaktive Patches in opatch

Wer kennt es nicht – man installiert ein ORACLE_HOME und installiert den aktuellen RU, ggfs. auch OJVM-Patch. Als braver DBA aktualisiert man regelmäßig, und schwuppdiewupp hat man einige (Dutzend) GB im Verzeichnis $ORACLE_HOME/.patchstorage… Das kostet nicht nur viel Platz, sondern auch immer mehr Zeit z.B. bei der Ausführung von datapatch, weshalb Oracle auch inzwischen empfiehlt, Out-of-Place zu patchen. Aber dann wiederum muss man den Platz für das neue Home bereitstellen, ggfs. Skripte anpassen usw… und alles nur, weil teilweise steinalte Patches immer noch für den Fall eines Rollbacks im .patchstorage-Ordner „für gut verwahrt“ werden.

Weiterlesen

Die Version 19.15 für die ODA kommt mit neuem Feature!

Das ODA-Software Release 19.15 wurde veröffentlicht, und das hat es in sich.
Ein neues Feature namens Data Preserving Reprovisioning ist nun verfügbar, mit welchem es möglich ist, eine deutlich veraltete ODA Version mit einem Schritt auf die 19.15 anzuheben.
Unterstützt sind aktuell folgende Quellversionen: 12.1.2.12, 12.2.1.4, 18.3, 18.5, 18.7, und 18.8.

Praxistest:
Ich kann also mit einem Schritt direkt von einer der o.g. genannten Versionen auf 19.15 upgraden? Das wird sofort getestet:

Weiterlesen

DataChangeRecorder der perfekte Zusatz für Ihre Oracle-Datenbank

Das Audit-Feature einer Oracle-Datenbank ist überaus mächtig und vielseitig. Wichtige Ereignisse, wie fehlerhafte Logins oder DDL-Operationen lassen sich stabil und sicher protokollieren. Bei der fein granularen Protokollierung von Änderungen ist man jedoch auf das Enterprise Edition Feature Fine Grained Auditing angewiesen. Im Umfeld der Standard Edition gibt es hierfür kein entsprechendes Pendant.

An dieser Stelle schließt der H&L DataChangeRecorder die Lücke, ganz gleich ob als Ergänzung zum bestehenden Funktionsumfang des Audit-Features oder als eigenständige Lösung. Zudem geht der DataChangeRecorder noch einen Schritt weiter und speichert die Änderungen auf Datensatz-und Feldebene ab. DCR protokolliert transaktionsbasiert jegliche Änderung bzw. DML-Operation (Insert, Update, Delete). Keine Datenänderung oder Datensatzlöschung geht mehr verloren. Der besondere Vorteil, die Details, welche Spalteninhalte geändert wurden oder welchen Inhalt ein Datensatz vor seiner Löschung hatte, werden ebenfalls protokolliert.

Über eine leicht zu bedienende Oberfläche lassen sich die Protokolleinträge sichten und auswerten. Eine Vorher-Nachher-Darstellung ist selbstverständlich enthalten. Über die Steuerungsoberfläche erfolgt die Konfiguration der Überwachungsobjekte.

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

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

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: