漏洞到底要不要修?

早就被发现的Log4j2安全漏洞

Log4j2安全漏洞被爆出以后，该漏洞波及范围之广，危害之大，也让各大软件安全厂商针对这个漏洞做出了补丁。该漏洞被编号为CVE-2021-44228，这个漏洞最早是被阿里发现的，但实则这是个0day漏洞，在国内发现该漏洞以前国外已经利用该漏洞一段时间了。其实该漏洞并不难被发现，使用SAST工具、SCA工具都可以发现该漏洞，但为何没有重视呢？或者说为什么没有修复呢？

2021年12月初，Log4j2漏洞报出后，我们公司的研究员分别用我们自己的静态应用安全测试工具CodeSec3.2以及Fortify17.1进行了扫描。

扫描结果如下：

logging-log4j2-log4j-2.0-beta9 -存在漏洞的版本

CodeSec3

 

Fortify17.1

 

logging-log4j2-rel-2.15.0 - 已经修复的版本

CodeSec3.2

 

Fortify17.1

 

可以看到的是老牌SAST工具Fortify17.1的版本就已经可以检测出该漏洞且报出级别为高危漏洞，而我们国产工具开源网安CodeSec3.2也顺利的检测出该漏洞并报出级别为中危漏洞扫描出来后风险等级报的是中危。由此可见这个漏洞其实很早就可能被人发现了,那为何不去修复呢？这其实是一个很引人思考的一个问题。

而修复后的版本两个工具检测出来都出现了误报。原因有：1.因为是静态扫描，特征匹配的单行代码“return (T) this.context.lookup(name)”只要

此特征，存在就报出来-漏洞存在。

2.并没有 根据上下文，判断，在上一句异常处理中已经return null 处理掉了绕过的可能。

漏洞发现后-理想很丰满现实很骨感

其实在理想状况下（不考虑成本的状况下），发现了漏洞，开发都是要去对这个漏洞进行修复的，但是在实际的现实生活当中，开发们只会去修复一些当前状况下可被利用高的漏洞，而那些目前不可被利用的低危漏洞 ，可能就不会被修复了。

为什么呢？

在风险评级方法中理论上我们是根据风险=可能性*影响这个模型来定级的。而这个可能性和影响还需要进一步的一个判断。在这些判断的因素当中，对于公司一方来说，漏洞被利用所造成的财产损失、声誉损失、是否合规、是否侵犯隐私这些因素也影响着他们发现漏洞后是否去修复。与此同时漏洞修复所需要的成本以及预算也是公司决定是否去修复的一大因素。

我们首先要清楚的一点是，当发现漏洞时，现有的产品对漏洞风险等级的报出的级别均基于过去的经验及技术，但是时代和技术是在不断更新迭代的，这也就意味着也许目前报出为低危的漏洞，当技术进步时这也可能会成为一个严重的漏洞，待人们对此有了新的评定后才会对产品的一个评定标准进行更改。换言之，因为黑客的“技术发展”，使得漏洞风险提高，某种程度上也推动了网络安全产品的一个升级发展。

软件开发商、安全组织及厂商、黑客和黑客组织都在努力的发现漏洞，谁先发现了可以说就是掌握了主动权。软件开发商先发现的话，它们可以选择进行修复推出个更为完美的软件。而安全组织及厂商发现的话，那可以在安全防护上做足准备而且能更好的更新安全产品。那么当黑客发现并且利用了漏洞在先那么就将会造成极大的损失了。

那究竟为什么当时发现却不去修复呢？

其实这个事情在现实生活当中有很多相似的例子，好比汽车烧机油，也并不是每个车主都会选择去修，或者更换发动机来解决这个问题。这好比是汽车的漏洞，一个中危风险的漏洞。它不会影响汽车本身对于使用者的一个基本功能，依旧可以驾驶，给使用者带来便利，而如果拿去修有时间成本、金钱成本、还有因为时间成本所带来的其余损失，又或者是因为修发动机拆机可能带来别的一些新的问题，从而产生更多的成本，所以很多车主可能会选择使用发动机修复剂等成本较低的方式。但如果有充足的预算大家都会选择直接换上一个全新的车来彻底解除这个漏洞风险。毕竟面对这样一个中危的漏洞没有人能保证哪天这个漏洞它就爆发了。可能行驶过程中就自燃了，这都是不可控的。而最初这个车本身也是一部完美没问题没漏洞的车啊，但是随着时间推移加上许多的人为因素从而导致这变成了一个漏洞，甚至可能因这个漏洞会带来巨大的损失及危害。

那么当我们在软件开发的过程当中，扫描检测出漏洞后，你说这究竟修还是不修呢？