IBM获得缺省值(以减轻CVE-2021-44228 AKA Log4Shell漏洞)

Question

如何在Java (IBM )上转储默认值以检查下列默认值？

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

类似的情况，但是对于上面的参数：

java -XX:+PrintFlagsFinal -version

这是一个CVE-2021-44228缓解审查。

理想情况下，这可以在cmd上检查，而不需要运行测试代码。

下面是我尝试的测试代码，它没有显示(display )：

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"));
    }
}

编译和运行：

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

Answer 1

CVE-2021-44228根据攻击者的想象创建了一个大的攻击面，而RCE只是其中之一。

我强烈建议您通过依赖针对某个攻击向量的JVM特性来避免得出错误的结论；还有更多的向量。只需将log4j-core设置为2.15.0或设置log4j2.formatMsgNoLookups=true系统属性即可。

Answer 2

回答问题的信

默认情况下，所讨论的系统属性似乎没有任何值。如果他们这样做了，你可以向以下机构查询：

java -XshowSettings:properties -version

请注意，-X标志是非标准的，尽管IBM支持这个标志(选中Semeru 11)。

至于上下文

The implementations (至少在OpenJDK中)查询属性值，如果属性未设置，默认为false。

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

因此，无论是-XshowSettings还是问题中的编程检查都无助于确切地了解JVM对于这些特性的默认行为，或者如果显式设置这些属性，运行的JVM版本是否会使用这些属性。

我同意沃尔坎点的观点，但我也想验证这些(危险的) JNDI特性是否是禁用的，而不管Log4j漏洞是什么。不幸的是，我们需要另一种方法来实现，理想的是独立于实现的方法。

Answer 3

升级到Log4j 2.15.x是不够的。还有另一个漏洞(参见https://www.zdnet.com/article/second-log4j-vulnerability-found-apache-log4j-2-16-0-released/)，一个新版本的JNDI 2.16已经发布，禁用默认的Log4j设置(https://logging.apache.org/log4j/2.x/download.html)并升级到2.16版本现在更重要了。

但是有许多Log4j克隆，定制代码使用相同的Log4j类，这就是为什么检查JVM设置很重要，特别是以前的JDK版本，如6u211、7u201和8u191，以及禁用JNDI + RMI设置。关于它的更多信息是2016年在黑帽上展示的。见https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf。