This post is about two security vulnerabilities reported on log4j 2.x framework: CVE-2021-44228, with a base score 10 (of 10 max.) in CVSS version 3.1 risk, and CVE-2021-45046, base scored 9. I will list some ways to determine affection, how to mitigate these vulnerabilities in general and Oracle Unified Directory in particular. Finally, there is a link with updated status to every Oracle software and why to migrate log4j 1.x to x >= 2.16.x.

Determine affection

  1. Use a vulnerability scanner
    It’s best to scan hosts company wide on a regular basis. I do not have experience here, use wikipedia as a (neutral) starting point. There is a useful list of scanners provided by OWASP (Open Web Application Security Project).
    To date, almost 166k CVE have been reported. The next vulnerability in software your are using will be reported sooner or later. It’s recommended to use a capable vulnerability scanner to landscape affection.
  2. Use log4j2-scan
    “log4j2-scan is a single binary command-line tool for CVE-2021-44228 vulnerability scanning and mitigation patch. It also supports nested JAR file scanning and patch. It also detects CVE-2021-45046 (log4j 2.15.0) and CVE-2021-4104 (log4j 1.x) vulnerabilities.”Download precompiled jar files or build your own
    How it works
    It runs in 5 steps:

      1. Find all .jar, .war, .ear, .aar files recursively.
      2. Find META-INF/maven/org.apache.logging.log4j/log4j-core/ entry from JAR file.
      3. Read groupId, artifactId, and version.
      4. Compare log4j2 version and print vulnerable version.
      5. If –fix option is used, backup vulnerable file and patch it.
        For example, original vulnerable.jar is copied to vulnerable.jar.bak

    Example: Analysing applications folder on macOS

    % java -jar logpresso-log4j2-scan-2.2.2.jar /Applications
    Logpresso CVE-2021-44228 Vulnerability Scanner 2.2.2 (2021-12-18)
    Scanning directory: /Applications
    [*] Found CVE-2021-44228 (log4j 2.x) vulnerability in /Applications/, log4j 2.8.1
    [*] Found CVE-2021-45046 (log4j 2.x) vulnerability in /Applications/, log4j 2.15.0
    Running scan (10s): scanned 14161 directories, 135423 files, last visit: /Applications/Microsoft
    Running scan (20s): scanned 25840 directories, 263162 files, last visit: /Applications/Microsoft
    Scanned 26789 directories and 276904 files
    Found 2 vulnerable files
    Found 0 potentially vulnerable files
    Found 0 mitigated files
    Completed in 20.85 seconds
  3. Find log4j jar files
    This is a fast, but not reliable method as log4j could simply be in a renamed jar file or nested. A jar file is a zip archive.
    1. As root/administrator, search for log4j jar files.
      Linux, Solaris, AIX, Mac OS, …:
      find / -name *log4j*
      dir /s /b <folder><pattern>
    2. Check version used. If below 2.16, you are affected:
      zip -p <jarfile> META-INF/MANIFEST.MF

How to mitigate?

Disable log4j JNDI lookups using the following parameter when startup a java application:
Usually, look for a file to add above parameter. Here is an example to start a jar file with parameter:
<JAVA JRE HOME>/bin/java -jar <jar-file> -Dlog4j2.formatMsgNoLookups=true <additional parameter>

What is properties file?
Most Java application need to use properties at some point, generally to store simple parameters as key-value pairs, outside of compiled code. And so the language has first class support for properties – the java.util.Properties – a utility class designed for handling this type of configuration files. Key-value pairs can be loaded from properties files. Popular file endings are .properties or .xml. As long as a file’s content meet properties file format requirements, it can be parsed correctly by Properties class.

Example: Oracle Unified Directory

It seems Oracle is still analysing the situation. I could not do mitigation according to official vendor information Doc ID 2827793.1, that is by deleting JndiLookup.class file which was not present. Personally, I think deleting files is suboptimal as it could lead to errors in logfiles when accessing them and errors may lead to false-positives incidents in monitoring.

As an alternative, I modified Java startup parameter to mitigate:

  1. Edit the file:
    <OUD instance home>/config/
  2. Add additional parameter:
  3. Activate changed properties:
    <OUD instance home>/bin/dsjavaproperties
  4. Restart OUD
    <OUD instance home>/bin/stop-ds --restart
  5. Check if OUD started using parameter
    ps -ef | grep Dlog4j2.formatMsgNoLookups

I’m looking forward for an official patch, which I will apply on test environment first.

log4shell & Oracle software

Please check this webpage on a regular basis.

Log4j 1.x

Log4j 1.x is not affected by above CVEs, but others. And it’s end of live, consider migrating to a version greater/equal 2.16.x