IBM java 獲取默認值（以緩解 CVE-2021-44228

Question

如何在 Java (IBM Java) 上轉儲默認值以檢查默認值

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

類似這樣的東西，但對於上述參數。

 java -XX:+PrintFlagsFinal -version

這是為了 CVE-2021-44228 緩解審查。

理想情況下，這可以在 cmd 上進行檢查，而無需運行測試代碼。

在這里我嘗試不顯示的測試代碼（顯示空）

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 Java 支持這一標志（檢查 Semeru 11）。

至於上下文：

實現（至少在 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 的觀點，但我也想驗證這些（危險的）JNDI 功能是否被禁用，無論 Log4J 漏洞利用如何。 不幸的是，盡管我們需要另一種方法來做到這一點，理想情況下是一種獨立於實現的方法。

Answer 3

我認為關閉這些功能將阻止使用 JNDI 的 RCE，而不僅僅是使用 Log4J2 的 RCE

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.15並升級Java到> Java 8u121

Answer 4

命令

jps -lvm

將 output 您正在運行的 java 進程及其參數。

另見這篇文章。

Answer 5

升級到 L4J 2.15.x 是不夠的。 還有另一個漏洞利用（參見https://www.zdnet.com/article/second-log4j-vulnerability-found-apache-log4j-2-16-0-released/ ）並且新版本 L4J 2.16 已經發布，已經禁用默認JNDI 設置（ https://logging.apache.org/log4j/2.x/download.html ）現在更重要的是升級到 2.16 版本。 但是有許多 L4J 克隆、使用相同 L4J 類的自定義代碼，這就是為什么檢查 JVM 設置很重要的原因，特別是對於 6u211、7u201 和 8u191 之前的 JDK 版本，並禁用 JNDI + RMI 設置。 2016 年在 BlackHat 上介紹了有關它的更多信息，請參閱https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE。 pdf 。