LOG4J漏洞深井冰【二】

2021-12-22 11:42:37 720

原本预计是没有二了,但是逼得一年没有写字的人出来蹦跶一下,一篇短文是写不完的。另外,和业界同行有了一些思想上的碰撞,又催生了一些自我思考反省,虽然有些问题没人愿意说,或者是真懂了、妥协了,甚至是视而不见,种种让我最终决定还是用自问自答的形式写下这篇二吧,这才真正暗应深井冰三个字的意思。


这个漏洞在JAVA生态8年了,为什么没有人更早一些提前发现?

这个其实是个很大的问题,不同经历的人会有不同答案。

经历过太多的人,每天我处理的漏洞是海量的,0day、nday、在野的不计其数,log4j这种漏洞会被淹没的。

专门做JAVA Web安全研究的人,2020年提交的Codeql代码扫描规则可以自动发现Log4Shell漏洞。这个回答会让我哭笑不得,是时候该反省8年JAVA安全是不是白学了。不过从我的安全经验看这个漏洞也没那么特别容易,涉及到可变变量、攻击入口的判断,还有影响面的评估,这个就看经验和悟性了。有时候原理简单,能看破,会利用的少,知行很难合一。不过综合评估这个漏洞的门槛实在不高,这也是让我纠结的点,业界确实发现和重视得太晚了,做相关研究的同学是该复盘一下了。

最重要的一点是开源社区的认知,开源社区认为这不是漏洞,是个强大功能带上的副作用,并且提供可控制的开关,所以安全社区不去逼一逼,是允许这种问题存在8年的,这也是我从业这么多年感到最可怕的事,但是在很多同行身上找不到共识,也许很多人是真懂了妥协了吧,而我只感到害怕。


为什么有人说这个漏洞不是打完补丁就完了,接下来是未来两年的战斗?

这个问题我觉得做JAVA开发的同学会很懂,不是把log4j2包删除升级就完事了,java的开发模式决定组件互相引用是指数级的,特别是log4j2包可以有嵌套打包、Fatjar包等形式,log4j2漏洞可能藏在JAVA生态的数万个包里面,这会让做防的人崩溃的,你并不知道你哪天引用开发的项目在不知不觉里踩地雷了,这又是内部安全开发流程、Devsecops要重新关注的点,而这仅仅是log4j2暴露出来的一个问题,还有无数个类似log4j2还没有披露的漏洞怎么办?


大公司部署的SCA安全软件对这个漏洞有没有帮助?

说实话,这是个我不愿意提及的问题,后知后觉,业界的很多安全产品、安全软件也受log4j2漏洞影响,局中人是该反省一下了,SCA软件自己就有SCA问题,安全产品自己就有RCE漏洞,这不讽刺么,这是唯一一个让我低下头的问题。


这个漏洞和永恒之蓝比起来谁更厉害?

永恒之蓝和Log4j2漏洞不一样,一个是操作系统漏洞,一个是一门语言生态的基础库出安全漏洞了,基础库的互相引用影响是指数级的,这是对业界生态的打击,不能放在一起比较。


对这个漏洞有什么好的解决方案和措施?

这个问题我要感谢NUKE兄弟,一直在不遗余力的推荐CISA的sbom(软件物料清单),SBOM 是描述软件包依赖树的一系列元数据,包括多种关键信息如提供商、版本号和组件名称的标准。我觉得每个组织机构经过log4j2的洗礼后,应该要重视起来了,SBOM的构建对于分析开源软件漏洞是发挥着关键作用的。


最后

用自问自答的方式还是舒服,至此LOG4J漏洞深井冰应该完了吧,看看下一年还有什么事会让我出来再写一篇。和我一样深井冰的朋友可以留言交流,深井冰久了对自己不太好 :)

微信公众号

新浪微博

电话咨询
解决方案
购买与服务
QQ客服