信息來源：FreeBuf

在剛剛過去的一月份，與往年相同，媒體們又在忙著報(bào)導(dǎo)過去一年的漏洞統(tǒng)計(jì)。同樣，CVE Details的小伙伴們也精心準(zhǔn)備了基于CVE（Common Vulnerabilities & Exposures，公共漏洞和暴露）統(tǒng)計(jì)的大把夸張數(shù)據(jù)。媒體朋友們也照例頻頻賞光咬餌，發(fā)布的都是諸如“安卓當(dāng)選2016漏洞之王”一類吸引眼球的頭條。（看著眼熟？）

盡管這些頭條可能每年都會讓熱衷此類話題的人覺得有趣，但安全研究者Craig Young卻認(rèn)為，在這種表象之下很少被提及的一點(diǎn)是：

這些統(tǒng)計(jì)數(shù)字幾乎毫無意義，也沒能就不同產(chǎn)品間的安全性做出任何比較。

下面這篇文章將解釋他這樣說的原因。同時，作者也鼓勵有興趣了解更多的人去觀看Steve Cristey和Brian Martin在2013年Black Hat大會上的講話“Buying into the Bias: Why Vulnerability Statistics Suck”（點(diǎn)擊觀看）

數(shù)據(jù)來源有限的CVE統(tǒng)計(jì)

我們可以這樣認(rèn)為：漏洞統(tǒng)計(jì)為產(chǎn)品安全提供了最直觀的指示。但同時我們也應(yīng)該意識到：從來就沒有，將來也不會存在一個真正意義上既綜合又完整的安全漏洞索引。CVE或其他漏洞數(shù)據(jù)庫只能記錄他們所知的漏洞，通常這些資料來自于廠商報(bào)告或由安全研究者提交。

遺憾的是，許多安全研究者往往并不會把他們發(fā)現(xiàn)的漏洞一個不剩地提交；廠商對于將漏洞公之于眾這種事也是習(xí)慣能躲就躲。（這種做法在學(xué)界有個稱呼：Publicatioin Bias——發(fā)表偏倚）。而那些未被發(fā)現(xiàn)的漏洞，和已確認(rèn)但易受黑客惡意攻擊的漏洞，在公布之前都不會被列入任何漏洞統(tǒng)計(jì)。這導(dǎo)致了某些廠商和軟件的漏洞統(tǒng)計(jì)數(shù)量虛高，這些廠商通常更愿意披露軟件的漏洞細(xì)節(jié)——比如說谷歌和Android。

當(dāng)CVE涉及產(chǎn)品面過寬時

同時，當(dāng)一個漏洞影響產(chǎn)品數(shù)量眾多時，CVE——尤其是CVE Details——對于漏洞的統(tǒng)計(jì)實(shí)際上不夠科學(xué)。之所以這么說，與一條CVE究竟如何命名，以及MITRE和CVE Details所掌握的有限資源是相關(guān)的。比如，不同產(chǎn)品可能會共享組件或代碼庫，但是CVE Details卻并不總是能把一個漏洞關(guān)聯(lián)到使用了問題代碼的全部產(chǎn)品上。

就拿WebKit來說，我們經(jīng)常會發(fā)現(xiàn)在審查Chrome時發(fā)現(xiàn)的漏洞（當(dāng)Chrome還在使用Webkit時）也會影響到Safari瀏覽器，CVE Details很少會把這樣的漏洞條目也關(guān)聯(lián)到Safari上。比如說CVE-2013-0912（點(diǎn)擊查看）——蘋果提供的報(bào)告已經(jīng)關(guān)聯(lián)到該CVE條目，但CVE Details卻并沒有把這個CVE綁定到任何版本的Safari上。這樣一來，2013年Chrome漏洞統(tǒng)計(jì)數(shù)上去了一個， Safari漏洞統(tǒng)計(jì)數(shù)卻差了一個。

再舉個例子：有些東西，像OpenSSL和Linux內(nèi)核使用得非常廣泛，一旦這兩者存在漏洞，則波及的產(chǎn)品也將非常廣泛——但實(shí)際情況是要將所有受影響的產(chǎn)品列舉出來是不現(xiàn)實(shí)的。那么現(xiàn)實(shí)又是如何呢？目前的做法一般是把上報(bào)的漏洞跟最先發(fā)現(xiàn)存在此漏洞的產(chǎn)品關(guān)聯(lián)起來。

忙不過來的MITRE

CVE的另一個問題在近幾年尤為突出：MITRE有些處理不過來海量的漏洞提交——詳情可回顧C(jī)VE命名申請?jiān)獯罅垦诱`（點(diǎn)擊查看）和CVE-assign郵件地址的最終停用（點(diǎn)擊查看）。而且要讓CVE條目最終公布，必須滿足某些條件，比如你得提交相關(guān)報(bào)告的URL或者發(fā)布關(guān)于此漏洞的博客文章。

針對不同漏洞報(bào)告，MITRE花費(fèi)的反應(yīng)時間也各不相同。有些幾小時內(nèi)就會處理好，有些則要花上幾周甚至幾個月——前提是MITRE理你的話。而且他們針對不同漏洞投入的時間，似乎與漏洞嚴(yán)重程度或軟件流行程度也沒什么關(guān)系。筆者曾在2015年末提交過一票CVE漏洞，但由于積卷如山，這些漏洞沒有得到任何反饋。而且筆者提交的CVE條目，有上百個從未被MITRE公布——廠商還沒有公開承認(rèn)這些漏洞，筆者表示也沒有時間把每一條漏洞都在博客里詳細(xì)闡明。

這些因素加在一起構(gòu)成了對處理安全問題認(rèn)真負(fù)責(zé)的廠商的抽樣偏差，也導(dǎo)致那些開源和有漏洞獎勵計(jì)劃的產(chǎn)品，在CVE-Details中的漏洞數(shù)量無端膨脹。

中槍的Android

開源就意味著運(yùn)用數(shù)據(jù)分析和Fuzzing工具（如American Fuzzy Lop）審查安全漏洞變得格外簡單。（這就要談到選擇偏見了，安全工作者更傾向于研究開源軟件或具有金錢激勵的產(chǎn)品）這使得開源軟件天生就在安全問題上顯得更加透明，因?yàn)楦拇a通常是有據(jù)可查的，而且研究者也沒有那么多的法律顧慮。

Bug賞金也扮演著重要角色，不僅是因?yàn)檫@使得研究者有仔細(xì)檢查產(chǎn)品，挖掘更多漏洞的動機(jī)，也是因?yàn)橥ㄓ闷脚_上存在的漏洞往往會與第一個曝出此問題的產(chǎn)品關(guān)聯(lián)起來。

這些因素加起來，使得大眾可能對像Android這樣一個開源，擁有bug賞金項(xiàng)目的系統(tǒng)產(chǎn)生了極度不靠譜的印象。此外，由于Android開源的本質(zhì)，有許多手機(jī)廠商生產(chǎn)了各種定制程序來支持某些特定硬件或提供某些全新功能。這些程序甚至都不一定包含在安卓官方的開源計(jì)劃中，但其中的漏洞卻仍然被算到CVE Details里Android系統(tǒng)的統(tǒng)計(jì)數(shù)據(jù)中去。

舉個例子，三星Galaxy系列智能手機(jī)曾被曝出自家代碼的一系列漏洞，這些漏洞最終都被歸結(jié)為Android系統(tǒng)的問題。但事實(shí)上它們除了Galaxy手機(jī)之外沒有影響到任何安卓設(shè)備。與此類似，有些Android系統(tǒng)中同樣可被利用的Linux內(nèi)核漏洞（如CVE-2016-7917），也被CVE Details歸類到Linux內(nèi)核問題而不是Android或其他任何Linux問題。

思考

作者在文末列舉了他認(rèn)為更值得關(guān)注的問題：假設(shè)有兩個相當(dāng)復(fù)雜的軟件包，有沒有一種方法能夠科學(xué)地比較兩者哪個安全性更高？有沒有一種方法能令人信服地衡量系統(tǒng)的安全程度？

作者認(rèn)為，這個問題實(shí)際上相當(dāng)復(fù)雜，他本人也沒有答案——信息安全通常被看做是計(jì)算機(jī)科學(xué)的一個分支，但信息安全在實(shí)操中缺少基本的科學(xué)論證方法。（點(diǎn)擊觀看視頻）