Android是今年的漏洞之王？CVE Details的數據根本就不靠譜！

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

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

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

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

數據來源有限的CVE統(tǒng)計

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

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

當CVE涉及產品面過寬時

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

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

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

忙不過來的MITRE

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

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

這些因素加在一起構成了對處理安全問題認真負責的廠商的抽樣偏差，也導致那些開源和有漏洞獎勵計劃的產品，在CVE-Details中的漏洞數量無端膨脹。

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

Bug賞金也扮演著重要角色，不僅是因為這使得研究者有仔細檢查產品，挖掘更多漏洞的動機，也是因為通用平臺上存在的漏洞往往會與第一個曝出此問題的產品關聯(lián)起來。

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

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

思考

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

作者認為，這個問題實際上相當復雜，他本人也沒有答案——信息安全通常被看做是計算機科學的一個分支，但信息安全在實操中缺少基本的科學論證方法。（點擊觀看視頻）

生成海報

免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。