世超|让全世界大厂都手忙脚乱的代码漏洞，是怎么一步步成为噩梦的？( 二 )

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

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

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

文章插图
这里世超用尽可能简单的说法解释了一下这个漏洞，如果差友们对具体的实现方式有兴趣，可以看下知乎上轩辕之风大佬的文章，介绍的很详尽了。
那么问题来了，为什么这个漏洞在被发现之后过了这么久，才被重视起来？
外行看热闹，内行看门道，有些事儿还真得问问业内人士。
于是世超咨询了国内知名的白帽网站——火线安全平台的小火子同学，聊了一通之后，大致了解了专业人士对这件事儿的看法。

文章插图
实际上 Log4J2 漏洞产生的原因，是因为部分程序员想要开发者保留在 Lookups 中 JNDI 的实现方式的旧功能而引起的。
根据 Log4J2 的维护者 Volkan Yaz?c? 的说法，他们早就想把这个有风险的功能给去了，但为了保证向后的兼容性，照顾到想要用这个功能的程序员，所以还是保留了下来。

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

文章插图
他们直接把问题往开源平台 Github 的 issue 里一贴，期待能有好心人给出解决问题得方案。
但这是个开放平台啊，有程序员同样也有黑客。。。
这波操作等于告诉了全世界的黑客： “ 咱这软件有高危漏洞哈，欢迎来捅！ ”

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

文章插图
可惜的是，等到所有用到使用 Log4J2 的业务系统反应过来有这个漏洞，已经过去了很长一段时间了。
因为使用 Log4J2 组件的软件实在太多，所以互联网公司的安全部门要一个个软件做修复和升级，这里头的工作量也可想而知。
目前最快的临时处理方案，是在 Log4J2 做一个触发式的拦截程序，类似于给系统先打上疫苗，把与漏洞相关内容，提前进行阻拦，和防火墙的原理差不多。
话说回来，世超觉得引发这次漏洞问题的锅，也不应该全由 Log4J2 的维护者来背。
说出来你可能不信，像 Log4J2 这么大一个开源项目，实际只靠几个程序员在业余时间来管理和维护，他们本身也是用爱发电，没有任何报酬的。
来自 Volkan Yaz?c? 推特下网友们的评论▼

文章插图
与之相反的是，包括像苹果、谷歌、亚马逊、特斯拉在内的这些大公司，都一定程度上在开心的 “ 白嫖 ” Log4J2 ，毕竟开源嘛，能省一点人力维护就省一点，反正总会有人维护的。。。
对于大厂开发者来说，这个来自十几年前仅有数人在维护的工具，只要能够完成产品，那凑合用就凑合用了，绝不重复造轮子。
并且争取在出现问题之前，成功跳槽。。。
可想而知，人人对于这类程序安全漏洞始终都是 “ 碰到了才明白出了问题 ”，谁知道整个行业都翻了车。

文章插图
尽管事儿已经是告一段落了，但这样大型的漏洞翻车事件，并不是第一次，也不会是最后一次发生，此类的 “ 黑天鹅事件 ” ，往往是不可预估且偶发性的。
而这一场场在网络世界中燃起的大火，唯有依靠程序员们的挑灯夜战，才得以熄灭。。。

文章插图