隨著軟件技術(shù)飛速發(fā)展，開源軟件已在全球范圍內(nèi)得到了廣泛應(yīng)用。數(shù)據(jù)顯示，從2012年起，已有超過80%的商業(yè)軟件使用開源軟件。開源軟件的代碼一旦存在安全問題，必將造成廣泛、嚴重的影響。為了解開源軟件的安全情況，CNCERT持續(xù)對廣泛使用的知名開源軟件進行源代碼安全缺陷分析，并發(fā)布季度安全缺陷分析報告。
本期報告聚焦國際知名互聯(lián)網(wǎng)公司的軟件安全開發(fā)現(xiàn)狀，通過檢測公司旗下多款開源軟件產(chǎn)品的安全缺陷，評估各公司的代碼安全控制情況。針對國際知名互聯(lián)網(wǎng)公司，選取關(guān)注度高的開源項目，結(jié)合缺陷掃描工具和人工審計的結(jié)果，對各公司的項目安全性進行評比。
1 被測開源軟件
參考Github機構(gòu)排名，本期報告聚焦國際知名互聯(lián)網(wǎng)公司Google、Facebook、Twitter，綜合考慮用戶數(shù)量、受關(guān)注程度等情況，選取了這些公司旗下的12款具有代表性的開源項目。本次被測的開源軟件項目的概況如下：
表1 被測開源軟件項目概覽
2 測試內(nèi)容
安全缺陷種類
本次測試涵蓋各類常見安全缺陷。根據(jù)缺陷形成的原因、被利用的可能性、造成的危害程度和解決的難度等因素進行綜合考慮，可以將常見的安全缺陷分為八類：
1）輸入驗證與表示（Input Validation and Representation）
輸入驗證與表示問題通常是由特殊字符、編碼和數(shù)字表示所引起的，這類問題的發(fā)生是由于對輸入的信任所造成的。這些問題包括：緩沖區(qū)溢出、跨站腳本、SQL注入、命令注入等。
2)API誤用（API Abuse)
API是調(diào)用者與被調(diào)用者之間的一個約定，大多數(shù)的API誤用是由于調(diào)用者沒有理解約定的目的所造成的。當(dāng)使用API不當(dāng)時，也會引發(fā)安全問題。
3)安全特性（Security Features）
該類別主要包含認證、訪問控制、機密性、密碼使用和特權(quán)管理等方面的缺陷。
4)時間和狀態(tài)（Time and State）
分布式計算與時間和狀態(tài)有關(guān)。線程和進程之間的交互及執(zhí)行任務(wù)的時間順序往往由共享的狀態(tài)決定，如信號量、變量、文件系統(tǒng)等。與分布式計算相關(guān)的缺陷包括競態(tài)條件、阻塞誤用等。
5)錯誤和異常處理缺陷（Errors）
這類缺陷與錯誤和異常處理有關(guān)，最常見的一種缺陷是沒有恰當(dāng)?shù)奶幚礤e誤（或者沒有處理錯誤）從而導(dǎo)致程序運行意外終止，另一種缺陷是產(chǎn)生的錯誤給潛在的攻擊者提供了過多信息。
6)代碼質(zhì)量問題（Code Quality）
低劣的代碼質(zhì)量會導(dǎo)致不可預(yù)測的行為。對于攻擊者而言，低劣的代碼使他們可以以意想不到的方式威脅系統(tǒng)。常見的該類別缺陷包括死代碼、空指針解引用、資源泄漏等。
7)封裝和隱藏缺陷（Encapsulation）
合理的封裝意味著區(qū)分校驗過和未經(jīng)檢驗的數(shù)據(jù)，區(qū)分不同用戶的數(shù)據(jù)，或區(qū)分用戶能看到和不能看到的數(shù)據(jù)等。常見的缺陷包括隱藏域、信息泄漏、跨站請求偽造等。
8)代碼運行環(huán)境的缺陷（Environment）
該類缺陷是源代碼之外的問題，例如運行環(huán)境配置問題、敏感信息管理問題等，它們對產(chǎn)品的安全仍然是至關(guān)重要的。
前七類缺陷與源代碼中的安全缺陷相關(guān)，它們可以成為惡意攻擊的目標，一旦被利用會造成信息泄露、權(quán)限提升、命令執(zhí)行等嚴重后果。最后一類缺陷描述實際代碼之外的安全問題，它們?nèi)菀自斐绍浖倪\行異常、數(shù)據(jù)丟失等嚴重問題。
安全缺陷級別
我們將源代碼的安全問題分為三種級別：高危（High）、中等（Medium）和低（Low）。衡量級別的標準包括兩個維度，置信程度（confidence）和嚴重程度（severity）。置信程度是指發(fā)現(xiàn)的問題是否準確的可能性，比如將每個strcpy函數(shù)調(diào)用都標記成緩沖區(qū)溢出缺陷的可信程度很低。嚴重程度是指假設(shè)測試技術(shù)真實可信的情況下檢出問題的嚴重性，比如緩沖區(qū)溢出通常是比變量未初始化更嚴重的安全問題。將這兩個因素綜合起來可以準確的為安全問題劃分級別，如下圖所示：
圖1 缺陷級別與嚴重程度、置信程度的關(guān)系
3 開源軟件項目的安全缺陷情況
本報告僅針對檢出的高危、中危缺陷進行統(tǒng)計和分析。本部分首先展示從被測項目中檢出安全缺陷的數(shù)量，并由此對三大互聯(lián)網(wǎng)公司的產(chǎn)品安全性進行比較。然后進一步討論各公司被測項目中安全缺陷的分布情況，了解各公司出現(xiàn)較多的缺陷類型。
安全缺陷情況概況
本部分展示被測項目查出缺陷的數(shù)量，由此對被測項目的安全性進行大致的評估。圖2展示了各個項目高危、中危缺陷的數(shù)量，并按照高危缺陷數(shù)量對項目進行了排序，圖中用藍色折線圖展示了每千行包含缺陷數(shù)。
圖2 開源軟件項目缺陷情況
在本次被測軟件中，來自Google的Protobuf（協(xié)議緩沖區(qū)）、來自Twitter的Fatcache（大數(shù)據(jù)緩存）不存在高危缺陷，同時中危缺陷的數(shù)量也相對較少。
來自Twitter的映射框架Libcrunch的高危缺陷數(shù)量居多，在15個高危缺陷中，存在9個路徑遍歷問題，5個空指針解引用缺陷和1個硬編碼密碼缺陷。
中高危缺陷總數(shù)最多的是來自Facebook的Rocksdb（持久鍵值存儲庫），包含94個中危缺陷，其中絕大多數(shù)也為代碼質(zhì)量類問題。例如，包含55個“類的構(gòu)造函數(shù)未對成員進行初始化”缺陷，32個“位運算的兩個操作數(shù)比特位數(shù)不同”缺陷。這些缺陷可能會導(dǎo)致程序發(fā)生不可預(yù)知的行為，甚至造成安全隱患，應(yīng)當(dāng)盡量避免。
由于項目的絕對缺陷數(shù)量可能與項目大小相關(guān)，因此本報告計算了每千行缺陷數(shù)，用該數(shù)據(jù)反映缺陷在項目中的分布密度。根據(jù)該數(shù)據(jù)，代碼安全性最好的項目依次是來自Google的Protobuf（0.00）、Oauth-java-client（0.06）、來自Facebook的Buck（0.07），這些軟件的每一千行代碼的平均安全缺陷數(shù)量小于0.1個。而缺陷分布密度相對較高的項目是來自Twitter的Libcrunch（5.43）、來自Google的UlforETW（1.41）和Google-java-format（1.09），這些軟件的每一千行代碼平均包含 1個以上的安全缺陷。
各公司產(chǎn)品安全性對比
本部分對不同互聯(lián)網(wǎng)公司的產(chǎn)品安全性概況進行對比，圖3展示了每個公司在本次測試中檢測出的高危、中危缺陷總數(shù)，以及以公司為單位統(tǒng)計的每千行缺陷數(shù) 。
圖3 互聯(lián)網(wǎng)公司產(chǎn)品安全性對比圖
由于每個公司的項目被檢測出缺陷的絕對數(shù)量與項目數(shù)量、項目大小相關(guān)，不能直接反映公司的產(chǎn)品安全性，因此本部分重點關(guān)注每千行缺陷數(shù)。根據(jù)該數(shù)據(jù)，Google的總體產(chǎn)品安全性較高，平均每一千行代碼僅包含0.07個安全缺陷。Twitter的總體產(chǎn)品安全性在3個公司中較差，平均每千行缺陷數(shù)量是Google本次抽樣產(chǎn)品的近6倍。
各公司高危缺陷分布情況
本部分展示各公司高危缺陷的分布情況，了解各公司出現(xiàn)較多的高危缺陷類型。如圖4所示，各公司的高危缺陷分布情況不盡相同。其中，普遍出現(xiàn)較多的高危缺陷是被污染的緩沖區(qū) 和空指針解引用。表2和表3分別列出了這兩種缺陷在各公司項目中的分布情況。
圖4 各公司高危缺陷分布情況
表2 高危被污染的緩沖區(qū)分布情況
| 公司名稱 | 各公司個數(shù) | 各公司比例 |
| 6 | 67% | |
| 0 | 0% | |
| 12 | 38% |
表3 高?？罩羔樈庖梅植记闆r
| 公司名稱 | 各公司個數(shù) | 各公司比例 |
| 0 | 0% | |
| 10 | 72% | |
| Twetter | 6 | 19% |
各公司中危缺陷分布情況
本部分繼續(xù)展示各公司中危缺陷的分布情況，了解各公司出現(xiàn)較多的中危缺陷類型。如圖5、圖6、圖7所示，各公司的中危缺陷分布情況不盡相同。由于中危缺陷的數(shù)量較多，為了方便展示，將僅出現(xiàn)1次的缺陷類型統(tǒng)一歸入“其他”。
圖5 Google中危缺陷分布情況
圖6 Facebook中危缺陷分布情況
圖7 Twitter中危缺陷分布情況
正如前文所述，3個公司軟件的中危缺陷絕大多數(shù)都為代碼質(zhì)量類問題，而普遍出現(xiàn)較多的兩類缺陷分別是“變量或參數(shù)等使用前未進行初始化”和“資源未及時釋放”，也均屬于代碼質(zhì)量類問題，這些缺陷雖然不易直接被攻擊者利用，但確實會造成程序運行不穩(wěn)定、性能下降甚至崩潰等問題。表4和表5分別列出了這兩種缺陷在各公司項目中的分布情況。
表4 中危未初始化問題分布情況
| 公司名稱 | 各公司個數(shù) | 各公司比例 |
| 5 | 19% | |
| 56 | 33% | |
| 5 | 14% |
表5 中危資源未釋放缺陷分布情況
| 公司名稱 | 各公司個數(shù) | 各公司比例 |
| 7 | 26% | |
| 37 | 22% | |
| Twetter | 20 | 54% |
4 關(guān)于本報告的說明
1、本報告僅從代碼角度進行缺陷分析。本報告中統(tǒng)計的缺陷是指由于代碼編寫不規(guī)范導(dǎo)致的有可能被攻擊者利用的安全隱患。在實際系統(tǒng)中，由于軟件實際部署環(huán)境、安全設(shè)備等的限制，部分缺陷可能無法通過滲透測試得到驗證。
2、本報告中的缺陷僅適用于表1中列出的特定軟件版本。當(dāng)軟件版本有任何更新、修改和優(yōu)化時，本報告不再適用。
3、本報告由360代碼衛(wèi)士團隊提供部分技術(shù)支持。
本文轉(zhuǎn)自：國家互聯(lián)網(wǎng)應(yīng)急中心CNCERT
