log4j2漏洞复现及修复

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
/**
 * @ClassName:LoggerTest
 * @author:dongao
 * @date 2021/12/14 13:03
 */
public class LoggerTest {
    private static final Logger logger = LogManager.getLogger();
    public static void main(String[] args) {
        String msg = "${java:vm}";
        logger.info("hello,{}",msg);
        logger.info("Try${date:YYYY-MM-dd}");
    }
}

ERROR StatusLogger Log4j2 could not find a logging implementation. Please add log4j-core to the classpath. Using SimpleLogger to log to the console...

针对以上结论，各项目自测操作如下

2021-12-15 10:03:02 [main] INFO  LoggerTest:17 - hello,Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
2021-12-15 10:03:02 [main] INFO  LoggerTest:18 - Try2021-12-15

10:03:52.394 [main] INFO com.example.demo.LoggerTest - hello,${java:vm}
10:03:52.405 [main] INFO com.example.demo.LoggerTest - Try${date:YYYY-MM-dd}

Affected Versions:
Elasticsearch versions 5.0.0+ contain a vulnerable version of Log4j. Elasticsearch 5 is susceptible to both remote code execution and an information leak via DNS. We’ve confirmed that the Security Manager mitigates the remote code execution attack in Elasticsearch 6 and 7.
Solutions and Mitigations:
The simplest remediation is to set the JVM option -Dlog4j2.formatMsgNoLookups=true and restart each node of the cluster.
For Elasticsearch 5.6.11+, 6.4+, and 7.0+, this provides full protection against the RCE and information leak attacks.
Users may upgrade to Elasticsearch 7.16.1 or 6.8.21, which were released on December 13, 2021. These releases do not upgrade the Log4j package, but mitigate the vulnerability by setting the JVM option -Dlog4j2.formatMsgNoLookups=true and remove the vulnerable JndiLookup class from the Log4j package.

Users should upgrade to Logstash 6.8.21 or 7.16.1 which were released on December 13, 2021. These releases replace vulnerable versions of Log4j with Log4j 2.15.0.

The widespread flag -Dlog4j2.formatMsgNoLookups=true is NOT sufficient to mitigate the vulnerability in Logstash in all cases, as Logstash uses Log4j in a way where the flag has no effect. If the user cannot upgrade to Logstash 7.16.1 or 6.8.21, it is necessary to remove the JndiLookup class from the log4j2 core jar, with the following command (which is applicable for 5.x, 6.x, and 7.x):
zip -q -d <LOGSTASH_HOME>/logstash-core/**/*/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLookup.class