Easily mitigate log4j vulnerability in Oracle Unified Directory

In December 2021, the critical vulnerability in Apache Log4j (CVE-2021-44228) was disclosed. With a CVSS rating of 10 out of 10, this vulnerability was or is extremely critical. Especially since Log4j is used relatively widely. Despite a great effort, many applications could only be corrected with a delay. Thus, it is not surprising that this vulnerability is still on our minds. This is also the case with Oracle Unified Directory in several customer projects. In this blog post I show how to find and install the appropriate patch for Oracle Unified Directory and check if the vulnerability is fixed.

Background

As with many other products, Oracle Unified Directory also includes the Apache Log4j library. In particular the directory oracle_common/modules/thirdparty includes a bunch of third party modules. Accordingly, the home directory of Oracle Unified Directory is in the focus of security scanners, which find the corresponding Apache Log4j library and identify it as a potential vulnerability. See also Oracle Support Document 2830143.1.

But as far as I know, Log4j is not used at all in a regular OUD instance. However, it seems reasonable to assume that this is the case. The Java head dump of an OUD instance at least does not list any corresponding Log4j classes. For a simple plausibility test, I used jProfiler to create a head dump of an Oracle Unified Directory instance and inspected the classes.

Java Head Dump of an OUD Instance

There are certainly other tools and better methods to verify this. But since I am not a Java developer, this simple test was sufficient for me.

What now? Oracle Unified Directory does not seem to use Log4j. But the security scanners still show a vulnerability. The easiest thing to do is to define a security exception and ignore the security finding at least for a while and wait for an official patch. It has been a while since December 2021. It will be difficult to justify the security exception for such a long time. So let’s look at possible mitigation measures.

Mitigation

At first, I assumed that the latest April 2022 bundle patch for Oracle Unified Directory would fix this vulnerability. But after the security scanner continued to show the Apache Log4j vulnerability on a new OUD instance with April 2022 bundle patch, I took a closer look. My mistake then was to first look for security fixes for Oracle Unified Directory. In doing so, I disregarded Fusion Middleware, especially Weblogic Server. Finally I made a standalone installation of Oracle Unified Directory to keep the size of the binaries small.

On the third attempt, I read the Oracle Support Document 2827793.1 a little more closely…

Scope of Oracle Support Document 2827793.1

It looks like I finally found my patch to fix CVE-2021-44228. Ok, you have to search a bit more until you find the correct patch.

Update in Oracle Support Document 2827793.1

With an update from April 19, reference is made to Oracle Support Document 2806740.2 Critical Patch Update (CPU) Patch Advisor for Oracle Fusion Middleware – Updated for July 2022. This is the Oracle Support Document, which is updated with every Critical Patch Advisory and lists the different patches for the whole Fusion Middleware Stack. Not so easy to find Oracle Unified Directory the first time. With time you get used to it. Oracle Unified Directory is listed under Identity & Access Management. If you select the current version 12.2.1.4, you get a table with the latest patches around Oracle Unified Directory.

Latest patches for Oracle Unified Directory 12.2.1.4 (Standalone)

Typical case of not reading closely. Anyway, in April I overlooked this patch and only installed the regular bundle patch for OUD. Any way, patching is then as usual easy.

  • Download the patch 34287807 to your directory server
  • Stop all OUD instances using a script or stop-ds
  • Unzip the patch
  • Install the patch using opatch apply
  • Start all OUD instances using a script or start-ds

In summary, the command line commands look like this.

stop-ds
cd /opt/stage
unzip p34287807_122140_Generic.zip
cd 34287807
$ORACLE_HOME/OPatch/opatch apply
start-ds

Verification

Verification is not that easy. Especially since I do not have the same security scanners as the customer. The first check is therefore with the OPatch tool. Below I just grep for Log4j to simplify the output.

$cdh/OPatch/opatch lsinventory -details|grep -i log4j
     compDef.xml --> ORACLE_HOME/inventory/Components/oracle.log4j.log4j/2.11.1.0.0/patches/24823841/compDef.xml
     oracle.log4j.log4j_2.11.1.0.0.xdiff --> ORACLE_HOME/inventory/Components/oracle.log4j.log4j/2.11.1.0.0/patches/24823841/oracle.log4j.log4j_2.11.1.0.0.xdiff
     log4j-2.11.1.jar --> ORACLE_HOME/oracle_common/modules/thirdparty/log4j-2.11.1.jar

As we see the name of the JAR is still log4j-2.11.1.jar. This makes it appear that Oracle is still using the version with the vulnerability. Let’s see what’s in the Manifest file.

unzip -q -c $ORACLE_HOME/oracle_common/modules/thirdparty/log4j-2.11.1.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0
Bundle-Description: The Apache Log4j Implementation
Implementation-Title: Apache Log4j
Bundle-SymbolicName: org.apache.logging.log4j
Implementation-Version: 2.17.1
Archiver-Version: Plexus Archiver
Built-By: Oracle
Specification-Vendor: The Apache Software Foundation
Specification-Title: Apache Log4j
Bundle-Vendor: The Apache Software Foundation
Implementation-Vendor: The Apache Software Foundation
Bundle-Version: 2.17.1
Created-By: Apache Maven 3.6.0
Build-Jdk: 1.8.0_221

It seems that at least the manifest file has been updated. Of course I hope that Oracle has also updated the corresponding classes. If the scanner only checks the filename it will still list a vulnerability. When checking the manifest file and/or the hash value of the classes, no vulnerability is listed anymore.

While searching for ways to easily check the Apache Log4j vulnerability, I came across the GitHub project rubo77/log4j_checker_beta. This project does provide a set of script and hash files to check the environment for possible Apache Log4j vulnerabilities. It is available for Linux, MacOS and Windows.

Let’s have a try and check what the script is finding on a system which just have been patched with 34287807.

curl -s https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -o /tmp/log4j_checker_beta.sh
chmod 755 /tmp/log4j_checker_beta.sh
sudo /tmp/log4j_checker_beta.sh -e /u01/app/oracle/product/oud12.2.1.4.0

An extract of a scan with the script looks as follows. You can see that the vulnerability was still found. However, the file with the old version of Apache Log4j is located in the $ORACLE_HOME/.patch_storage directory. This directory contains the old files and is used when patches need to be uninstalled again. To be able to install / uninstall patches correctly, you have to leave this directory as it is. See also Oracle Support Document 2852759.1.

sudo /tmp/log4j_checker_beta.sh -e /u01/app/oracle/product/oud12.2.1.4.0
[INFO] using default hash file. If you want to use other hashes, set another URL as first argument
[INFO] Created vulnerable hashes file from https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/hashes-pre-cve.txt

[INFO] Looking for files containing log4j...
[INFO] Using locate, which could be using outdated data. Be sure to have called updatedb recently
[WARNING] Maybe vulnerable, those files contain the name:
...
/u01/app/oracle/product/oud12.2.1.4.0/.patch_storage/34287807_Jun_16_2022_09_31_07/files/oracle.log4j.log4j/2.11.1.0.0/thirdparty.symbol/modules/thirdparty/log4j-2.11.1.jar
...
/u01/app/oracle/product/oud12.2.1.4.0/oracle_common/modules/thirdparty/log4j-2.11.1.jar
...
[INFO] Checking installed packages: (solr\|elastic\|log4j)
[INFO] No yum packages found

[INFO] Checking if Java is installed...
[INFO] Java is not installed

[INFO] Analyzing JAR/WAR/EAR files in /var /etc /usr /opt /lib* /u01/app/oracle/product/oud12.2.1.4.0 ...
[INFO] Also checking hashes
...
[WARNING] [463 - contains log4j files] /u01/app/oracle/product/oud12.2.1.4.0/oracle_common/modules/thirdparty/log4j-2.11.1.jar
...
[WARNING] [1308 - vulnerable binary classes] /u01/app/oracle/product/oud12.2.1.4.0/.patch_storage/34287807_Jun_16_2022_09_31_07/files/oracle.log4j.log4j/2.11.1.0.0/thirdparty.symbol/modules/thirdparty/log4j-2.11.1.jar
...
[INFO] Found 1314 files in unpacked binaries containing the string 'log4j' with 1 vulnerabilities
[WARNING] Found 1 vulnerabilities in unpacked binaries
[INFO] _________________________________________________
[WARNING] Some apps bundle the vulnerable library in their own compiled package, so even if 'java' is not installed, one of the applications could still be vulnerable.

[WARNING] This script does not guarantee that you are not vulnerable, but is a strong hint.

Conclusion

The Apache Log4j has been around for a while and is relatively easy to fix in the meantime. As we have seen, it can also be fixed with Oracle Unified Directory. From that point of view, this blog post does not convey breaking news at this point. Since I had to deal with this topic several times in the past in a couple of projects, I have put together this information. I hope one or the other will find this helpful as well.

Finally, a few notes to myself 🙄:

  • Read Oracle support documents carefully. Sometimes they contain an update.
  • Oracle Unified Directory is and will remain a part of Oracle Fusion Middleware. Therefore, general information and patches are also relevant.
  • Always study the whole list of patches in Oracle Support Document 2806740.2 Critical Patch Update (CPU) Patch Advisor for Oracle Fusion Middleware – Updated for July 2022

References

Some references and hints on this topic:

  • Apache Log4j Security Vulnerabilities
  • NIST vulnerability database CVE-2021-44228
  • CVE MITRE database CVE-2021-44228
  • Oracle Support Document 2830143.1 Impact of December 2021 Apache Log4j Vulnerabilities on Oracle on-premises products (CVE-2021-44228, CVE-2021-45046)
  • Oracle Support Document 2847142.1 General impact of Apache Log4j vulnerabilities on Oracle Products and Services
  • Oracle Support Document 2827611.1 Impact of December 2021 Apache Log4j Vulnerabilities on Oracle Products and Services (CVE-2021-44228, CVE-2021-45046)
  • Oracle Support Document 2827793.1 Security Alert CVE-2021-44228 / CVE-2021-45046 Patch Availability Document for Oracle WebLogic Server and Fusion Middleware
  • Oracle Support Document 2806740.2 Critical Patch Update (CPU) Patch Advisor for Oracle Fusion Middleware – Updated for July 2022
  • Oracle Support Document 1074055.1 Security Vulnerability FAQ for Oracle Database and Fusion Middleware Products
  • Oracle Support Document 2768441.1 Details for Oracle Fusion Middleware Third-Party Component Updates
  • Oracle Support Document 2640772.1 Information And Bug Listing of Oracle Unified Directory Bundle Patches: 12.2.1.4.x (12cR2PS4) Version 
  • Oracle Support Document 2638933.1 Summarized Steps to Patch the Underlying Components Used in Oracle Unified Directory 12.2.1.4.x Installations
  • Oracle Support Document 2852759.1 Can Files be Deleted From the .patch_storage Directory After Patches Has Been Applied Successfully
  • rubo77/log4j_checker_beta Log4j check scripts for Linux, macOS and Windows Scripts
  • Common Vulnerability Scoring System version 3.1 Specification Document
  • Blog Post List All the Classes Loaded in the JVM