一不小心，Log4j炸了 一不小心潜了哥哥

这两天相信大家都看到了一个新闻：

在洋哥的技术大咖群，不少CTO/总监带的团队也中招了，很多公司都开始紧急通知，让团队排查Log4j2组件的使用和漏洞预防的问题。

为了防止有些小伙伴不知情导致代码和产品出问题，我今天也分享一波。

先来介绍下这个漏洞吧：

无论是做前端开发还是后端开发，我们都需要打日志，这玩意可以帮助我们定位程序出现的各种状况。

Log4j2就是Java技术栈中常用的日志系统，Log4j2是在Log4j基础上迭代过来的，做了很多改进和优化：

这玩意还是相当优秀的，面试之后可谓所向披靡、应用广泛。

漏洞详情：

存在漏洞的版本：Apache Log4j 2.x <= 2.14.1，Log4j2核弹级漏洞最初是阿里发现并公布出来的，不久前，阿里云安全团队向Apache官方报告了Apache Log4j2远程代码执行漏洞：

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

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

注意关键字：任意代码！这就很恐怖了，一旦启动相当于计算机就成了黑客的肉鸡，危害性可想而知！

JNDI注入：

先解释下JND:JNDI是Java命名与目录接口，提供了用名称访问资源的能力:

如上图所示，JNDI提供统一的客户端API，通过不同的服务供应接口(SPI)的实现，由管理者将JNDI API映射为特定的命名服务和目录系统，使得Java应用程序可以和这些命名服务和目录服务之间进行交互。

通过JNDI，可以访问已经在命名和目录服务器中注册的服务对象。

JNDI注入就是将恶意的Reference类绑定在RMI注册表中，再引用指向远程恶意的class文件，当用户在JNDI客户端的lookup()函数参数外部可控或Reference类构造方法的classFactoryLocation参数外部可控时，会使用户的JNDI客户端访问RMI注册表中绑定的恶意Reference类，从而加载远程服务器上的恶意class文件在客户端本地执行，最终实现JNDI注入攻击导致远程代码执行。

解决方法：

1.升级版本

排查应用是否引入了Apache log4j-core Jar包，若存在依赖引入，且在受影响版本范围内，则可能存在漏洞影响。

尽快升级Apache Log4j2所有相关应用到最新的 log4j-2.15.0-rc2 版本。

地址如下：

https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

2.换框架

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

但是换框架工作量应该挺大，并且要做好充分测试。

留给我们的思考：

还记得在腾讯做码农之际，我老板经常说的一句话就是：永远不要依赖单一框架或技术，因为他们都是人写的，都会出错。

在我们团队，最喜欢干的事情就是：做中间件整合多个框架，并且做到服务端控制切换，比如我们在处理游戏大厅和游戏多进程通信之际，就使用了管道(pipe)、共享内存和socket三套实现，一旦哪一种出问题会自动掉另一种，也可以通过后台切换方案。

这之后我带技术团队的要求也是这样了，比如在360，我们的很多系统就是做的中间层，整合了几个方案，哪个出问题就迅速切一下解决了。

技术人，永远不要把命运交付他人之手，别人优秀的东西可以用，但也一定要小心再小心呀，要用技术的手段尽量让自己立于不败之地～