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

Question

how can I dump on Java (IBM Java) the default values to check default of

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

something like this but for the above parameter.

 java -XX:+PrintFlagsFinal -version

This is for CVE-2021-44228 mitigation review.

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

Here 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 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, eg

        // 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

I would assume that turning these feature off will prevent RCE using JNDI, not just the one using Log4J2

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.15 and upgrade Java to > Java 8u121

Answer 4

The command

jps -lvm

will output your running java processes with their parameters.

See also this post .

Answer 5

The upgrade to L4J 2.15.x is not enough. There is another exploit (see https://www.zdnet.com/article/second-log4j-vulnerability-found-apache-log4j-2-16-0-released/ ) and new version L4J 2.16 has been published already disabling default JNDI settings ( https://logging.apache.org/log4j/2.x/download.html ) and upgrade to 2.16 version is more important now. But there are many L4J clones, custom codes using the same L4J 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 on BlackHat in 2016 see https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf .