皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

Android 是今年的漏洞之王?CVE Details 的数据根本就不靠谱!

CVE.jpg

在刚刚过去的一月份,与往年相同,媒体们又在忙着报导过去一年的漏洞统计。同样,CVE Details 的小伙伴们也精心准备了基于 CVE(Common Vulnerabilities & Exposures,公共漏洞和暴露)统计的大把夸张数据。媒体朋友们也照例频频赏光咬饵,发布的都是诸如“安卓当选 2016 漏洞之王”一类吸引眼球的头条。看着眼熟?

尽管这些头条可能每年都会让热衷此类话题的人觉得有趣,但安全研究者 Craig Young 却认为,在这种表象之下很少被提及的一点是:

这些统计数字几乎毫无意义,也没能就不同产品间的安全性做出任何比较。

下面这篇文章将解释他这样说的原因。同时,作者也鼓励有兴趣了解更多的人去观看 Steve Cristey 和 Brian Martin 在 2013 年 Black Hat 大会上的讲话“Buying into the Bias: Why Vulnerability Statistics Suck”(点击观看

数据来源有限的 CVE 统计

我们可以这样认为:漏洞统计为产品安全提供了最直观的指示。但同时我们也应该意识到:从来就没有,将来也不会存在一个真正意义上既综合又完整的安全漏洞索引。CVE 或其他漏洞数据库只能记录他们所知的漏洞 ,通常这些资料来自于厂商报告或由安全研究者提交。

遗憾的是,许多安全研究者往往并不会把他们发现的漏洞一个不剩地提交;厂商对于将漏洞公之于众这种事也是习惯能躲就躲。(这种做法在学界有个称呼:Publicatioin Bias——发表偏倚)。而那些未被发现的漏洞,和已确认但易受黑客恶意攻击的漏洞,在公布之前都不会被列入任何漏洞统计。 这导致了某些厂商和软件的漏洞统计数量虚高,这些厂商通常更愿意披露软件的漏洞细节——比如说谷歌和 Android。

当 CVE 涉及产品面过宽时

同时,当一个漏洞影响产品数量众多时,CVE——尤其是 CVE Details——对于漏洞的统计实际上不够科学。之所以这么说,与一条 CVE 究竟如何命名,以及 MITRE 和 CVE Details 所掌握的有限资源是相关的。 比如,不同产品可能会共享组件或代码库,但是 CVE Details 却并不总是能把一个漏洞关联到使用了问题代码的全部产品上。

就拿 WebKit 来说,我们经常会发现在审查 Chrome 时发现的漏洞(当 Chrome 还在使用 Webkit 时)也会影响到 Safari 浏览器,CVE Details 很少会把这样的漏洞条目也关联到 Safari 上。比如说 CVE-2013-0912(点击查看)——苹果提供的报告已经关联到该 CVE 条目,但 CVE Details 却并没有把这个 CVE 绑定到任何版本的 Safari 上。这样一来,2013 年 Chrome 漏洞统计数上去了一个, Safari 漏洞统计数却差了一个。

再举个例子:有些东西,像 OpenSSL 和 Linux 内核使用得非常广泛,一旦这两者存在漏洞,则波及的产品也将非常广泛——但实际情况是要将所有受影响的产品列举出来是不现实的。那么现实又是如何呢?目前的做法一般是把上报的漏洞跟最先发现存在此漏洞的产品关联起来。

忙不过来的 MITRE

CVE 的另一个问题在近几年尤为突出:MITRE 有些处理不过来海量的漏洞提交 ——详情可回顾 CVE 命名申请遭大量延误(点击查看)和 CVE-assign 邮件地址的最终停用(点击查看)。 而且要让 CVE 条目最终公布,必须满足某些条件, 比如你得提交相关报告的 URL 或者发布关于此漏洞的博客文章。

针对不同漏洞报告,MITRE 花费的反应时间也各不相同。有些几小时内就会处理好,有些则要花上几周甚至几个月——前提是 MITRE 理你的话。而且他们针对不同漏洞投入的时间,似乎与漏洞严重程度或软件流行程度也没什么关系。笔者曾在 2015 年末提交过一票 CVE 漏洞,但由于积卷如山,这些漏洞没有得到任何反馈。而且笔者提交的 CVE 条目,有上百个从未被 MITRE 公布——厂商还没有公开承认这些漏洞,笔者表示也没有时间把每一条漏洞都在博客里详细阐明。

这些因素加在一起构成了对处理安全问题认真负责的厂商的抽样偏差,也导致那些开源和有漏洞奖励计划的产品,在 CVE-Details 中的漏洞数量无端膨胀。

安卓手机.jpg

中枪的 Android

开源就意味着运用数据分析和 Fuzzing 工具(如 American Fuzzy Lop)审查安全漏洞变得格外简单。(这就要谈到选择偏见了, 安全工作者更倾向于研究开源软件或具有金钱激励的产品)这使得开源软件天生就在安全问题上显得更加透明,因为更改代码通常是有据可查的,而且研究者也没有那么多的法律顾虑。

Bug 赏金也扮演着重要角色,不仅是因为这使得研究者有仔细检查产品,挖掘更多漏洞的动机,也是因为通用平台上存在的漏洞往往会与第一个曝出此问题的产品关联起来。

这些因素加起来,使得大众可能对像 Android 这样一个开源,拥有 bug 赏金项目的系统产生了极度不靠谱的印象。此外, 由于 Android 开源的本质,有许多手机厂商生产了各种定制程序来支持某些特定硬件或提供某些全新功能。 这些程序甚至都不一定包含在安卓官方的开源计划中,但其中的漏洞却仍然被算到 CVE Details 里 Android 系统的统计数据中去。

举个例子,三星 Galaxy 系列智能手机曾被曝出自家代码的一系列漏洞,这些漏洞最终都被归结为 Android 系统的问题。但事实上它们除了 Galaxy 手机之外没有影响到任何安卓设备。与此类似,有些 Android 系统中同样可被利用的 Linux 内核漏洞(如 CVE-2016-7917),也被 CVE Details 归类到 Linux 内核问题而不是 Android 或其他任何 Linux 问题。

思考

作者在文末列举了他认为更值得关注的问题:假设有两个相当复杂的软件包,有没有一种方法能够科学地比较两者哪个安全性更高?有没有一种方法能令人信服地衡量系统的安全程度?

作者认为,这个问题实际上相当复杂,他本人也没有答案——信息安全通常被看做是计算机科学的一个分支,但信息安全在实操中缺少基本的科学论证方法。(点击观看视频

分享到:更多 ()