IBM java get defaults (to mitigate CVE-2021-44228

Question

How can I dump on Java (IBM Java) the default values to check the default of the following?

"com.sun.jndi.rmi.object.trustURLCodebase"
"com.sun.jndi.cosnaming.object.trustURLCodebase"

Something like this, but for the above parameters:

java -XX:+PrintFlagsFinal -version

This is for a CVE-2021-44228 mitigation review.

Ideally this can be checked on cmd and not need to run test code.

Here is my attempt of test code which doesn't show (display Null):

import java.util.Properties;

class TiloDisplay
{
    public static void main(String[] args)
    {
        Properties prop = System.getProperties();
        printProperties(prop);
    }

    public static void printProperties(Properties prop) {
        prop.stringPropertyNames().stream()
                .map(key -> key + ": " + prop.getProperty(key))
                .forEach(System.out::println);
        System.out.println("CVE check part ========================================== " );
        System.out.println("CVE check for:: com.sun.jndi.ldap.object.trustURLCodebase: " + prop.getProperty("com.sun.jndi.ldap.object.trustURLCodebase"));
        System.out.println("CVE check for:: com.sun.jndi.rmi.object.trustURLCodebase: " + prop.getProperty("com.sun.jndi.rmi.object.trustURLCodebase"));
        System.out.println("CVE check for:: com.sun.jndi.cosnaming.object.trustURLCodebase: " + prop.getProperty("com.sun.jndi.cosnaming.object.trustURLCodebase"));
        System.out.println("Cross Check: " + prop.getProperty("java.version"));
    }
}

Compile and run:

javac DisplayApp.java -source 1.8 -target 1.8
java TiloDisplay

Answer 1

CVE-2021-44228 creates a large attack surface depending on the imagination of the attacker and an RCE is just one of them.

I would strongly advise you to avoid having a false conclusion by relying on a JVM feature targeting a certain attack vector; there are more vectors. Simply either bump log4j-core to 2.15.0 or set the log4j2.formatMsgNoLookups=true system property.

Answer 2

Answering the letter of the question:

It does not appear that the system properties in question have any value by default. If they did, you could check with:

java -XshowSettings:properties -version

Note that -X flags are non-standard, though IBM Java supports this one (checked Semeru 11).

As for the context:

The implementations (in OpenJDK at least) query for the property values, defaulting to false if the properties are unset, e.g.,

// System property to control whether classes may be loaded from an
// arbitrary URL code base
String trust = getPrivilegedProperty(
        "com.sun.jndi.ldap.object.trustURLCodebase", "false");
trustURLCodebase = "true".equalsIgnoreCase(trust);

So neither -XshowSettings nor the programmatic check in the question are helpful to know for certain what behavior your JVM defaults to for these features, or if the JVM version you're running uses these properties at all if you set them explicitly.

I agree with Volkan's point, but I also would like to verify that these (dangerous) JNDI features are disabled regardless of the Log4j exploit. Unfortunately though we need another way to do that, ideally an implementation-independent one.

Answer 3

The upgrade to Log4j 2.15.x is not enough. There is another exploit (see Second Log4j vulnerability discovered, patch already released) and a new version Log4j 2.16 has been published already, disabling the default JNDI settings (Download Apache Log4j 2) and upgrade to 2.16 version is more important now.

But there are many Log4j clones, custom code using the same Log4j classes and that is why it's important to check the JVM settings, especially for previous JDK versions as prior to 6u211, 7u201 and 8u191 and disable JNDI + RMI settings. More about it was presented at Black Hat in 2016. See A journey from JNDI/LDAP manipulation to remote code execution dream land.

Answer 4

The command

jps -lvm

will output your running Java processes with their parameters.

See also this answer to Getting the parameters of a running JVM.

Answer 5

I would assume that turning these feature off will prevent remote code execution (RCE) using JNDI, not just the one using Log4j 2:

log4j2.formatMsgNoLookups -> set to true
"com.sun.jndi.rmi.object.trustURLCodebase" -> set to false
"com.sun.jndi.cosnaming.object.trustURLCodebase" -> set to false

Upgrade Log4J2 to 2.17.1 and upgrade Java to higher than Java 8u121.