Spring Boot Log4j2漏洞修复指南 (Log4J2 Vulnerability and Spring Boot)

前言
一句话总结issue：如果你使用的是 Log4j 1.x、Logback 或者其他日志框架，这次就可以幸免于难。如果你使用Spring Boot默认日志，也是没有问题的，因为默认是Commons Logging。
一句话修复solution：升级springboot到最新v2.5.8和v2.6.2以及后续版本，确保安全；如果单独依赖了log4j2日志，请强制使用最新版本v2.15.0换切换其他日志系统或者追加参数-Dlog4j2.formatMsgNoLookups=true。

UPDATE：

2021/12/14 09:30 新增RCA
2021/12/14 22:00 加更：log4j2官方已推送中央仓库2.16.0版本
2021/12/15 07:30 加更：ESET NOD32发布Apache Log4j漏洞解决方案，列举部分受影响的框架/平台
Reference:

log4j 2.16.0 MVNREPOSITORY

官方指南Log4J2 Vulnerability and Spring Boot

ESET发布Apache Log4j漏洞解决方案，请政企客户检查更新！

背调
正如您在新闻中所看到的，针对流行的 Log4J2 库的新零日漏洞利用已被报道，该库可允许攻击者远程执行代码。 该漏洞已通过针对 log4j-core jar 的 CVE-2021-44228 报告，并已在 Log4J v2.15.0 中修复。

此漏洞由Lookup功能引发，Log4j在默认情况下会开启Lookup功能，提供给客户一种添加特殊值到日志中的方式。此功能中也包含了对JNDI的Lookup，但由于Lookup对加载的JNDI内容未做任何限制，使得攻击者可以通过JNDI注入实现远程加载恶意类到应用中，从而造成RCE。

漏洞定位: log4j的真正漏洞代码出现在log4j-core的子组件。修复其他组件不一定能有效消除漏洞。很多产品都产生了误报的行为，但是为了安全起见，建议使用专业的分析平台或者强制升级比较稳妥，以绝后患。

部分受影响框架
目前受影响的Apache Log4j2版本：2.0 ≤ Apache Log4j <= 2.14.1

可能的受影响应用包括但不限于如下：

Spring-Boot-strater-log4j2
Apache Struts2
Apache Solr
Apache Flink
Apache Druid
ElasticSearch
flume
dubbo
Redis
logstash
kafka
Spring Boot 用户如何处理
Spring Boot 用户只有在将默认日志系统切换到 Log4J2 时才会受到此漏洞的影响。 我们包含在 spring-boot-starter-logging 中的 log4j-to-slf4j 和 log4j-api jar 不能被单独利用。 只有使用 log4j-core 并在日志消息中包含用户输入的应用程序容易受到攻击。

Spring Boot 即将发布的 v2.5.8 和 v2.6.2 版本（2021 年 12 月 23 日到期）将采用 Log4J v2.15.0，但由于这是一个如此严重的漏洞，您可能希望覆盖我们的依赖项管理并尽快升级您的 Log4J2 依赖项。

Maven 处理log4j2指南
对于 Maven 用户，您可以按照这些说明进行设置 log4j2.version 属性.

<properties>
    <log4j2.version>2.15.0</log4j2.version>
</properties>
1
2
3
如何确认是否成功修复？运行 ./mvnw dependency:list | grep log4j检测版本是否为2.15.0.

通过JVM参数处理漏洞
如果程序/系统很难升级，则可以选择追加参数避免该漏洞。
设置log4j2.formatMsgNoLookups系统参数为true即可
例如

java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar.

设置系统环境变量解决
将系统变量“LOG4J_FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS” 设置为 “true”

powered by zhengkai.blog.csdn.net

设置log4j2.component.properties解决
在项目 classpath 目录下添加 log4j2.component.properties 配置文件，设置 log4j2.formatMsgNoLookups=true

如何查看框架的log4j版本
可以通过maven仓库分解对应的log4j版本
https://mvnrepository.com

Jfinal与log4j漏洞有关吗
例如Jfinal,可以通过maven仓库分解对应的log4j版本
https://mvnrepository.com/artifact/com.jfinal/jfinal/4.1

拆解得知是1.2.16，安全！

如果你使用最新版本4.9.7，也是安全的，因为用的还是1.2.x
https://mvnrepository.com/artifact/com.jfinal/jfinal/4.9.17

spring-boot-starter-logging
可以到 https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-logging/2.5.7

例如你使用了spring-boot-starter-logging 2.5.7 ，包含了log4j的2.14.1版本，还是相当危险，最好等待官方发最新 2.5.8

Spring-Boot-strater-log4j2更是绝对的危险，等候官方推送新版解决。

使用Scantist SCA检测及分析
Scantist SCA平台 https://scantist.io , 来源

为了解决开源软件的漏洞检测和管理的问题，Scantist SCA产品是一套完整的解决方案，同时支持源码和二进制扫描，通过提供对应用程序软件供应链的更大可视性，主动帮助企业管理开源库的安全性和合规性风险。Scantist SCA通过分析软件应用程序中已知的第三方库和组件的特殊签名，并与漏洞和许可证数据库进行交叉对比，以识别软件开发和部署阶段中的安全隐患。

分析报告

加更：Log4J 2.16.0修复版发布
修复Log4J2 Vulnerability问题

log4j 2.16.0 MVNREPOSITORY

更新内容：

删除了消息Lookups。目的是采取强化措施以防止 CVE-2021-44228，此举措不是修复 CVE-2021-44228所必须的。

虽然版本 2.15.0 删除了处理Lookups和利用JNDI从日志消息和地址访问的问题，Log4j团队认为默认启用 JNDI 会引入未知的风险。从版本 2.16.0 开始，JNDI 功能是默认情况下禁用，可以通过 log4j2.enableJndi重新启用系统属性。在不受保护的上下文中使用 JNDI 是一个很大的问题 安全风险，应该在这个库和 所有其他使用 JNDI 的 Java 库。

在 2.15.0 版本之前，Log4j 会在模式布局（Pattern Layout）中包含的消息或参数中自动解析 Lookups。这行为不再是默认值，必须通过指定启用%msg{lookup}。：

修正错误

LOG4J2-3208：默认禁用 JNDI。需要 log4j2.enableJndi设置为 true 以允许 JNDI。 LOG4J2-3211：完全删除对消息查找的支持。

Apache Log4j 2.16.0 至少需要 Java 8 才能构建和运行。Log4j 2.12.1 是最后一个支持 Java 7 的版本。Java 7 不是Log4j 团队的长期支持版本。

有关 Apache Log4j 2 的完整信息，包括有关如何提交错误报告、补丁或改进建议，请参阅 Apache Apache Log4j 2 网站：

https://issues.apache.org/jira/browse/LOG4J2-2975

https://logging.apache.org/log4j/2.x/download.html

ESET快速响应模块检测拦截此漏洞： JAVA/Exploit.CVE-2021-44228
ESET已经在全球范围内推动了组件更新，请确保“快速响应模块”已经更新到版本19417以上

————————————————
版权声明：本文为CSDN博主「Moshow郑锴」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/moshowgame/article/details/121917232