IBM Java 获取默认值（以缓解 CVE-2021-44228 AKA Log4Shell 漏洞）答案

【问题标题】：IBM Java get defaults (to mitigate CVE-2021-44228 AKA Log4Shell vulnerability)IBM Java 获取默认值（以缓解 CVE-2021-44228 AKA Log4Shell 漏洞）
【发布时间】：2022-01-15 09:35:29
【问题描述】：

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

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

类似这样，但对于上述参数：

java -XX:+PrintFlagsFinal -version

这是针对CVE-2021-44228 缓解审查。

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

这是我尝试的不显示（显示 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"));
    }
}

编译运行：

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

【问题讨论】：

标签： java websphere

【解决方案1】：

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

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

【讨论】：

你是对的@Vokan，但这仍然是一个有效的问题......
优秀而正确的指导，但它属于评论。

【解决方案2】：

回答问题：

默认情况下，相关系统属性似乎没有任何值。如果他们这样做了，您可以检查：

java -XshowSettings:properties -version

请注意，-X 标志是非标准的，尽管 IBM Java 支持这一标志（检查 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 版本是否完全使用这些属性（如果您明确设置它们） .

我同意Volkan's point，但我也想验证这些（危险的）JNDI 功能是否被禁用，无论 Log4j 漏洞如何。不幸的是，尽管我们需要另一种方法来做到这一点，理想情况下是一种独立于实现的方法。

【讨论】：

【解决方案3】：

我认为关闭这些功能将阻止 remote code execution (RCE) 使用 JNDI，而不仅仅是使用 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

将Log4J2升级到2.17.1，Java升级到Java 8u121以上。

【讨论】：

它们在所有最近的 java 版本中都被关闭了，但这并不能防止对 JNDI 的反序列化攻击。

【解决方案4】：

命令

jps -lvm

将输出您正在运行的 Java 进程及其参数。

另见this answer to Getting the parameters of a running JVM。

【讨论】：

【解决方案5】：

升级到 Log4j 2.15.x 还不够。还有另一个漏洞利用（请参阅Second Log4j vulnerability discovered, patch already released），并且已经发布了新版本 Log4j 2.16，禁用默认 JNDI 设置 (Download Apache Log4j 2) 并升级到 2.16 版本现在更重要了。

但是有许多 Log4j 克隆，使用相同 Log4j 类的自定义代码，这就是为什么检查 JVM 设置很重要的原因，特别是对于 6u211、7u201 和 8u191 之前的早期 JDK 版本并禁用 JNDI + @987654324 @设置。 2016 年在Black Hat 上介绍了有关它的更多信息。请参阅A journey from JNDI/LDAP manipulation to remote code execution dream land。

【讨论】：