让全世界大厂都手忙脚乱的代码漏洞，是怎么一步步成为噩梦的？_风闻

本文原创于微信公众号：差评  作者：世超

最近几天，世超在各家互联网大厂的程序员朋友们，都快被一个叫 Log4Shell 的史诗级漏洞给折磨疯了！

这个漏洞源于一个叫 Log4J2 （ Log For Java 2 ）的 Java 开源日志框架，它在用 Java 敲代码的码农群体里可以说是无人不知，无人不晓。

它就好像早年间打《 魔兽世界 》一定要装的大脚插件一样，属于真正意义上的**“ 咖啡伴侣 ”**，很少有 Java 程序不用这个组件。

就是这么一个要命的底层日志框架，被发现透了一个洞。。。

最先发现漏洞的，是阿里云安全团队中，一位叫 Chen Zhaojun 的大佬。

据他的说法，这个漏洞很早就被国外的安全代码扫描平台扫出来了，圈内的程序员大佬们也都在等待官方的修复，没有声张。

 “ 上百万刀的安全架构，在 Log4J2 漏洞面前一文不值。。。 ” ▼

很快啊，包括了阿里、腾讯、百度、网易、新浪等一众国内的互联网大厂纷纷中枪，都被圈在了受影响的范围之内。

有博主还收到了腾讯云发来的防护短信。 ▼

不仅仅是大厂的服务系统，耳机、电脑、车机等硬件系统等也无一幸免。。。

不夸张的说，这个漏洞要是不及时修补，下场就是被如饥似渴的黑客们捅烂，进一步威胁网络安全。

他们会有效利用**“ 零日漏洞 ”**（ 指的是发现后立即被恶意利用的安全漏洞 ）发动零时差攻击，抢在安全补丁出来之前，对服务器造成杀伤。

就连我们日常使用的手机、电脑软件（ 大部分都是拿 Java 写的 ），也都将暴露在黑客的的攻击范围内，想捅哪里捅哪里，把你的电脑挟持过来挖矿也不是没可能。

就和打游戏偷家似的， so easy 。。。

不过有意思的是，也有乐子人利用这个漏洞，发现了特斯拉把国内数据上传到美利坚服务器的尴尬事儿。

不知道这个数据有没有包含用户数据，但我建议龙马哥先别急着解释这茬了，还是赶紧把这个漏洞修修吧，不然到时候可能真的不好收场。

咳咳，扯远了。。。

说回这次的漏洞，最可怕的地方在于实现起来没什么门槛，只要用一串简单的字符，就能轻易攻破服务器，并在上面运行各种代码。。。

这别说是窃取个人信息了，黑客想要远程挟持、瘫痪企业级的服务器，那也是毫无阻碍。

那黑客到底是怎么样利用漏洞，用几串字符就轻松攻破服务器的呢？

要整明白这个问题，我们得先搞清楚啥是日志。

众所周知啊，程序员在敲完一段代码之后，肯定不可能马上拿来用，而要通过反复的测试来验证代码的可行性。

但代码本身在跑的时候，处于一个黑箱状态，如果放任它瞎跑的话，跑到一半卡住，根本不知道是错在哪一步上。

这就好像是做数学题时候如果没草稿纸，在心里算总是没个底。

这时候，日志的作用就体现出来了，它就好像是一大张草稿纸，能在上面做任何你自己看的懂得步骤和标记，方便随时随地验算。

本质上日志是程序员们经常使用的一个工具，它把代码在测试过程中的每一步都给记录下来，跑完再回头 Debug 的时候，就很有针对性，效率也高。

而 Log4J2 ，就是这么一个开源的日志框架，它里面整合了不少在修改代码时会用到的常用功能，比如日志管理、输出变量等实用功能。

这次的高危漏洞就是源于 Log4J2 中一个叫 Lookups 的功能。

从字面上理解，这个功能就是一个用来搜索内容的接口，想要搜些啥，那就要靠代码去实现了。

Log4J2 也在 Lookups 的功能下，提供了不少实现的途径，问题就出在这个叫 JNDI 的途径上。

JNDI 被 Java 允许通过远程连接的方式来加载文件，这个远程地址可以是开发者自己的服务器，也可以是外界的服务器。

坏就坏在这个远程下载上了。。。

黑客只要通过 JNDI 的方法连接上自己的恶意服务器，就可以堂而皇之从这个接口进来，继而攻破整栋固若金汤的大厦。

这里世超用尽可能简单的说法解释了一下这个漏洞，如果差友们对具体的实现方式有兴趣，可以看下知乎上轩辕之风大佬写的这篇文章，介绍的很详尽了。

https : //zhuanlan.zhihu.com/p/444103520

那么问题来了，为什么这个漏洞在被发现之后过了这么久，才被重视起来？

外行看热闹，内行看门道，有些事儿还真得问问业内人士。

于是世超咨询了国内知名的白帽网站——火线安全平台的小火子同学，聊了一通之后，大致了解了专业人士对这件事儿的看法。

实际上 Log4J2 漏洞产生的原因，是因为部分程序员想要开发者保留在 Lookups 中 JNDI 的实现方式的旧功能而引起的。

根据 Log4J2 的维护者 Volkan Yazıcı 的说法，他们早就想把这个有风险的功能给去了，但为了保证向后的兼容性，照顾到想要用这个功能的程序员，所以还是保留了下来。

**好嘛，小洞不补、大洞吃苦，**这个高危漏洞被发现之后， Log4J2 实际的管理机构 Apache 软件基金会并没能引起足够的重视，披露漏洞的流程也没有按流程来走。

他们直接把问题往开源平台 Github 的 issue 里一贴，期待能有好心人给出解决问题得方案。

但这是个开放平台啊，有程序员同样也有黑客。。。

这波操作等于告诉了全世界的黑客：“ 咱这软件有高危漏洞哈，欢迎来捅！ ”

甚至在漏洞全面爆发之前，就已经有白客们在 issue 中公开讨论过具体的修复细节。

可惜的是，等到所有用到使用 Log4J2 的业务系统反应过来有这个漏洞，已经过去了很长一段时间了。

因为使用 Log4J2 组件的软件实在太多，所以互联网公司的安全部门要一个个软件做修复和升级，这里头的工作量也可想而知。

目前最快的临时处理方案，是在 Log4J2 做一个触发式的拦截程序，类似于给系统先打上疫苗，把与漏洞相关内容，提前进行阻拦，和防火墙的原理差不多。

话说回来，世超觉得引发这次漏洞问题的锅，也不应该全由 Log4J2 的维护者来背。

说出来你可能不信，像 Log4J2 这么大一个开源项目，实际只靠几个程序员在业余事件来管理和维护，他们本身也是用爱发电，没有任何报酬的。

来自 Volkan Yazıcı 推特下网友们的评论▼

与之相反的是，包括像苹果、谷歌、亚马逊、特斯拉在内的这些大公司，都一定程度上在开心的**“ 白嫖 ”**Log4J2 ，毕竟开源嘛，能省一点人力维护就省一点，反正总会有人维护的。。。

对于大厂开发者来说，这个来自十几年前仅有数人在维护的工具，只要能够完成产品，那凑合用就凑合用了，绝不重复造轮子。

并且争取在出现问题之前，成功跳槽。。。

可想而知，人人对于这类程序安全漏洞始终都是**“ 碰到了才明白出了问题 ”**，谁知道整个行业都翻了车。

尽管事儿已经是告一段落了，但这样大型的漏洞翻车事件，并不是第一次，也不会是最后一次发生，此类的**“ 黑天鹅事件 ”**，往往是不可预估且偶发性的。

而这一场场在网络世界中燃起的大火，唯有依靠程序员们的挑灯夜战，才得以熄灭。。。

特别鸣谢：火线安全

图片、资料来源：

微博：@程序员的那些事

微博：@Flanker_017

微博：@主动干饭猫

知乎：核弹级漏洞！我把log4j扒给你看！

新智元：中国程序员抢先预警「史诗」级漏洞，席卷苹果特斯拉

开源中国：Log4j 维护者：为向后兼容没移除导致漏洞的旧功能

Twitter：@yazicivo

Mitigating the log4j Vulnerability (CVE-2021-44228) with NGINX