IBM Java get defaults (to mitigate CVE-2021-44228 AKA Log4Shell vulnerability)

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

score 9 · Answer 1 · edited Jan 10 '22 at 15:44

9

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.

edited Jan 10 '22 at 15:44

Peter Mortensen

30,738
21
105
131

answered Dec 10 '21 at 19:31

Volkan Yazıcı

1,530
1
15
28

2

You are right @Vokan, but it is still a valid question... – ixe013 Dec 14 '21 at 14:25
Excellent and correct guidance, but it belongs in an comment. – Amit Naidu Dec 14 '21 at 23:09

score 7 · Answer 2 · edited Jan 10 '22 at 15:47

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.

Venod Raveendran · Answer 3 · 2022-01-11T16:02:50.867

2

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.

edited Jan 11 '22 at 16:02

answered Dec 11 '21 at 12:22

Venod Raveendran

73
6

2

They are turned off in all recent java versions, but this does not prevent de-serialisation attacks against JNDI. – eckes Dec 11 '21 at 23:26

score 2 · Answer 4 · edited Jan 10 '22 at 16:08

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.

score 1 · Answer 5 · edited Jan 10 '22 at 15:59

1

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.

edited Jan 10 '22 at 15:59

Peter Mortensen

30,738
21
105
131

answered Dec 13 '21 at 11:08

pascalre

305
1
4
20

IBM Java get defaults (to mitigate CVE-2021-44228 AKA Log4Shell vulnerability)

5 Answers5