开源一夏 |log4j2 漏洞复现及修复

2022 年 8 月 25 日
北京
本文字数：2854 字
阅读完需：约 9 分钟

【写在前面】log4j2 漏洞的风波已经过去挺久了，这里写在这里主要是为了告诉大家一种查找问题的方式或者说遇到类似问题应该如何排查处理的方法。下面开始本文的正文内容

1.漏洞复现

搭建简单 maven 项目，编写测试方法类：LoggerTest.java

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

复制代码

情景一

只引入 log4j-core.2.11.1.jar 包测试结果：

版本升级为 2.15.0.jar 包后测试结果：

情景二

只引入 log4j-api.2.11.1.jar 包会报如下错误：

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

复制代码

报错处理后测试结果：

只升级 log4j-api 版本为 2.15.0.jar 包后测试结果：

只升级 log4j-core 版本为 2.15.0.jar 包后测试结果：

同时升级 log4j-api、log4j-core 为 2.15.0 后测试结果：

情景三

搭建 springboot 项目引入 log4j-core.2.11.1.jar

版本测试结果：

结果未出现 log4j2 漏洞问题

如果删除 springboot 相关 jar 包，再补充 log4j2.xml 配置文件，注释掉 DemoApplication.java，此时再次测试结果：

此时的项目实际也不再是 springboot 项目。

2.项目审查

本部门的项目引用的 springboot 框架的项目，项目本身用的是 springboot 默认的 logback 日志，而上例中情景三搭建的 springboot 项目即使在引入存在安全漏洞 jar 包 log4j-core 的前提下,依然不曾检测到漏洞问题，回到项目中，项目 ei-crm-admin 也是 logback 日志输出的项目，且测试方法在项目中也未测出漏洞反应，测试结果如下图：

3.结论

1.项目中同时引入 log4j-api、log4j-core,需同时升级为 2.15.0 版本 jar 包，如果只升级 log4j-core 会出现情景二中异常

2.项目中只是引入 log4j-api,可以不用升级，但是如果将 log4j2 作为日志输出的话还是需要 log4j-core，此时升级参考上一条

3.springboot 项目即使引入有问题 log4j-core 版本的 jar 包也无法出现漏洞反应，而项目中 logback 和 log4j2 只能选一存在，springboot 默认选择 logback 日志，而我们部门 springboot 项目也是 logback 日志，且验证的也没有问题，故虽然项目中第三方 jar 包的内部引用了低版本 log4j2，但也应无安全问题，另公司内网服务器均已关闭了主动访问外网服务，综合而言应无此次漏洞引发的问题。

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

复制代码

4.项目自测

首先引入测试方法类 LoggerTest.java，直接执行查看结果，可能会有两种结果：

结果一：

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}

复制代码

其中结果一即为 log4j2 漏洞反应输出，结果二为正常日志输出。

5.kafka

(1).测试环境 kafka 通过命令查看是否引入 log4j2 jar 包

kafka 版本较低，无 log4j-core jar 包，log4j-api jar 包版本不在漏洞版本范围内；

(2).线上环境 kafka 版本通过运维查询得知 kafka 版本号为 2.10-0.8.2.1

本地下载对应版本 kafka 安装包解压后看到

故而线上 kafka 由于版本较低，也无此次 log4j2 漏洞问题

6.elasticsearch

测试环境、线上环境 elasticsearch 版本均是 6.7.1，查看服务器 jar 可看到

引入了 log4j-api-2.11.1.jar 、 log4j-core-2.11.1.jar 包，且用的是 log4j2 日志，考虑到直接升级 elasticsearch 版本或者升级 jar 包有一定风险，参考 elasticsearch 官网解决方案：

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.

复制代码

链接elastic

也可参考其他处理方案：

Log4j 漏洞修复和临时补救方法

其中【1.设置 jvm 参数 “-Dlog4j2.formatMsgNoLookups=true” 2.设置“log4j2.formatMsgNoLookups=True”】可操作性、安全性、改动也是最小的，风险较低，本地测试结果如下：

这样在改动最小，风险最低的情况下解决此次 log4j2 的漏洞风险。

7.logstash

测试环境、线上环境 logstash 版本均是 6.7.1，查看服务器 jar 可看到

引入了 log4j-api-2.9.1.jar、log4j-core-2.9.1.jar 包，且用的是 log4j2 日志，官网也提供了 logstash 新版来解决当前问题，

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.

复制代码

但是贸然升级存在一定风险，且版本跨度较大，风险未知，若想通过更改 jvm.options 来增加参数

-Dlog4j2.formatMsgNoLookups=true 来缓解 logstash 中的漏洞，此方法行不通，因为 logstash 是以标志无效的方式使用 log4j 的，同时官网也提供了以下解决方案：

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

复制代码

删除 JndiLookup.class 文件

考虑到部分服务器可能没有 zip 命令，故可以本地删除后重新覆盖更新原有 jar 包。

更改完成后重新启动 logstash 即可。

从运维处得知本部门内网服务器满足【4.关闭对应应用的网络外连，禁止主动外连】均不会主动访问外网服务，故 elasticsearch、logstash 也可暂时不用操作。

发布于: 刚刚阅读数: 3

原文链接:【http://xie.infoq.cn/article/f98f84a98b3c93552d47cf33b】。

六月的雨在infoQ

关注

让技术不再枯燥，让每一位技术人爱上技术 2022.07.22 加入

还未添加个人简介

发布

暂无评论

创作场景

开源一夏 |log4j2 漏洞复现及修复

1.漏洞复现

情景一

情景二

情景三

2.项目审查

3.结论

4.项目自测

5.kafka

6.elasticsearch

7.logstash

六月的雨在infoQ

评论