一種開源代碼缺陷識別系統(tǒng)的實現(xiàn)

軟件開發(fā)是一項復(fù)雜的任務(wù)，尤其是現(xiàn)在軟件技術(shù)飛速發(fā)展，開發(fā)環(huán)境不斷演變，軟件架構(gòu)和組成變得多樣化。企業(yè)使用開源軟件的比例越來越高，軟件主要由自主開發(fā)代碼、開源代碼和開源組件組裝而成。其中，開源代碼、開源組件提供了必要的構(gòu)建塊，使組織能夠交付價值、提高質(zhì)量、降低風(fēng)險并縮短上線時間。但同時其衍生出的軟件安全管理問題也越來越多，軟件團隊只關(guān)注檢測自主代碼的潛在問題，往往忽視了對應(yīng)用組件構(gòu)成和應(yīng)用所包含的開源代碼中已知漏洞和開源協(xié)議的檢查。盡管安全人員和開發(fā)人員不斷通過安全編碼指南制定、軟件測試和各種形式的代碼審查等辦法來提高軟件質(zhì)量和安全性，但通用漏洞披露（CommonVulnerabilities&Exposures，CVE）的數(shù)據(jù)記錄顯示，漏洞數(shù)量依舊呈增長趨勢。鑒于軟件的整體安全性高度依賴于軟件漏洞的識別和緩解能力。因此，高效的分析代碼中存在的漏洞可以幫助開發(fā)人員識別并修復(fù)源代碼中的缺陷。本文提出了一種自動發(fā)現(xiàn)源代碼中安全漏洞的方案，通過從開放漏洞數(shù)據(jù)庫中抽取所有可用的CVE記錄，并從相關(guān)的開源項目所在的開源存儲庫中收集易受攻擊的代碼，建立開源缺陷代碼庫。利用搜索引擎與源代碼分析規(guī)范多樣化聯(lián)合應(yīng)用，根據(jù)不同結(jié)構(gòu)的代碼相似性特征，挖掘代碼缺陷庫中的缺陷匹配信息，具有較高的缺陷搜索匹配速度和準(zhǔn)確性。1代碼缺陷分析現(xiàn)狀1.1靜態(tài)代碼分析技術(shù)靜態(tài)代碼分析是白盒測試的一種方法，通過代碼檢查可以確定代碼和設(shè)計的一致性、代碼結(jié)構(gòu)的合理性、代碼編寫的標(biāo)準(zhǔn)性和可讀性、代碼邏輯表達的正確性等。靜態(tài)代碼缺陷分析是指在不運行目標(biāo)程序的前提下分析目標(biāo)程序（源代碼或二進制）的詞法、語法和語義等，并結(jié)合程序的數(shù)據(jù)流、控制流信息，通過類型推導(dǎo)、安全規(guī)則檢查、模型檢測等技術(shù)挖掘程序中的漏洞。靜態(tài)漏洞挖掘是常用的軟件測試技術(shù)，在軟件測試中占有非常重要的地位。具有代表性的靜態(tài)漏洞挖掘工具包括：面向C/C++源碼的Cppcheck、FlawFinder[3]，面向PHP源碼的RIPS，面向Java源碼的FindBugs，以及能支持多種類型目標(biāo)對象的著名商業(yè)化漏洞檢測工具VeraCode、Fortify、Coverity、Checkmarx等。另外，LLVM[5]、Clang[6]等編譯器也為軟件源代碼提供了大量的靜態(tài)檢測功能，從而在編譯階段實現(xiàn)對源代碼的安全性檢查。1.2問題分析靜態(tài)代碼分析技術(shù)主要用于挖掘未知問題，發(fā)現(xiàn)潛在的不安全及不規(guī)范的代碼，但是不涉及被測軟件的運行及動態(tài)驗證，這與漏洞掃描、滲透測試、病毒掃描等方面的技術(shù)原理完全不同，因此靜態(tài)代碼分析技術(shù)存在的誤報問題往往給開發(fā)人員帶來困擾，尤其是在信息系統(tǒng)頻繁迭代開發(fā)場景下的多次檢測會顯著增加開發(fā)人員的工作量，開發(fā)人員或?qū)徲嬋藛T需要大量精力用于排除靜態(tài)分析誤報問題。軟件主要由自主開發(fā)代碼、開源代碼和開源組件組裝而成。自主開發(fā)代碼的缺陷是未知的，但是開源代碼存在的缺陷卻是公開的，因此，可以基于公開漏洞庫，從開源項目所在的開源代碼庫中收集易受攻擊的代碼建立開源缺陷代碼庫，用于軟件中開源代碼的缺陷識別。相對于傳統(tǒng)的靜態(tài)代碼分析，此技術(shù)路線具有較高的準(zhǔn)確性。2開源代碼缺陷識別系統(tǒng)本文提出一種開源代碼缺陷識別方案，能夠快速準(zhǔn)確地識別軟件代碼中存在的開源代碼缺陷。通過抽取已知的開源代碼中的缺陷信息構(gòu)建缺陷知識庫，利用搜索技術(shù)和代碼分詞多種規(guī)范化表達方式，在目標(biāo)代碼中可以有效地識別已知代碼缺陷（精準(zhǔn)搜索）和缺陷變體（相似搜索）。開源代碼缺陷識別系統(tǒng)架構(gòu)如圖1所示，系統(tǒng)分為缺陷數(shù)據(jù)處理流程、缺陷數(shù)據(jù)索引流程和缺陷代碼搜索3個模塊。圖1開源代碼缺陷識別系統(tǒng)架構(gòu)2.1缺陷數(shù)據(jù)處理流程首先構(gòu)建缺陷代碼知識庫，為了保障分析效果，知識庫應(yīng)包含多個級別的缺陷代碼粒度，例如與缺陷代碼相關(guān)的文件、類、函數(shù)等，并涵蓋廣泛使用的編程語言。本研究通過在CVE記錄中自動收集漏洞描述信息，挖掘托管在GitHub、GitLab和Bitbucket以及開源項目自有代碼管理庫上的代碼缺陷記錄，收集易受攻擊的代碼樣本。CVE數(shù)據(jù)信息主要來自美國國家計算機通用漏洞數(shù)據(jù)庫（NationalVulnerabilityDatabase，NVD），這是一個由美國國家標(biāo)準(zhǔn)與技術(shù)研究院（NationalInstituteofStandardsandTechnology，NIST）維護的漏洞管理數(shù)據(jù)庫。NIST使用各種數(shù)據(jù)源發(fā)布整個NVD數(shù)據(jù)庫供安全人員使用，漏洞數(shù)據(jù)包含漏洞源、安全檢查、與安全相關(guān)的軟件缺陷、錯誤配置、產(chǎn)品名稱和缺陷影響。缺陷描述文件包含每日更新的CVE漏洞信息，對于較早期的缺陷信息描述，主要按照來源年份有序排列發(fā)布。在CVE的描述文件中，每個漏洞都有CVE-ID標(biāo)號、發(fā)布日期、描述、關(guān)聯(lián)參考鏈接、易受攻擊的產(chǎn)品配置、通用缺陷枚舉（CommonWeaknessEnumeration，CWE）缺陷分類和其他指標(biāo)。每個漏洞的嚴(yán)重性都使用通用漏洞評分系統(tǒng)（CommonVulnerabilityScoringSystem，CVSS）進行排名。CVSS由3個指標(biāo)組成，即基礎(chǔ)、時間和環(huán)境，漏洞的特征和上下文信息。漏洞影響評分系統(tǒng)存在兩個版本：CVSSv2和CVSSv3，它們都對缺陷進行細致描述。CVSSv3為CVSSv2的升級描述，用來更準(zhǔn)確地對漏洞進行影響評分，并提供更多信息來區(qū)分不同類型的漏洞。當(dāng)開源項目中的漏洞被修復(fù)時，CVE記錄信息將更新，增加一個或多個指向相關(guān)源代碼存儲庫的引用，包括修復(fù)缺陷時提交記錄生成的哈希。這些信息可用來在本研究中作為代碼缺陷庫的組成信息。缺陷數(shù)據(jù)處理流程如圖2所示。圖2缺陷數(shù)據(jù)處理流程2.1.1收集CVE記錄信息采集工具從NVD服務(wù)器檢索所有已發(fā)布的JSON格式的漏洞源，搜集范圍包括2002年首次發(fā)布到收集之日最后一次發(fā)布的CVE。然后對獲取到的JSON文件進行聚合、加工和處理，濾掉CVE記錄中所有在reference字段中沒有與之關(guān)聯(lián)的修復(fù)程序CVE記錄信息，因為這些CVE無法收集相應(yīng)的易受攻擊或已修復(fù)的代碼。在處理和過濾完缺陷記錄后，CVE記錄信息包括CVE-ID、發(fā)布日期、最后修改日期、參考數(shù)據(jù)、CVSS嚴(yán)重性評分、漏洞影響和范圍、可利用性評分等漏洞的描述。通常，CVE缺陷類型由CWE進行分類，因此還需要收集這些CWE類型的詳細信息，并將它們與適當(dāng)?shù)腃VE記錄進行映射，用來區(qū)分具體的缺陷類型。2.1.2修復(fù)記錄提取在分析CVE缺陷記錄信息時，只分析存在修復(fù)記錄的CVE，通過提取修復(fù)CVE記錄信息中與代碼相關(guān)的開源倉庫信息，利用git工具在本地克隆代碼項目，并根據(jù)CVE記錄中提交的哈希值，通過git來收集有關(guān)易受攻擊的缺陷代碼信息，包括代碼的語言、版本、發(fā)布時間、CVE記錄、CWE記錄、存儲庫地址信息、提交記錄、受影響的文件和受影響的方法等信息，并將收集到的信息存儲在數(shù)據(jù)庫中。2.1.3構(gòu)建元數(shù)據(jù)信息CVE中涉及開源項目相關(guān)的代碼庫信息主要來自GitHub、GitLab和Bitbucket，其中項目所屬GitHub的比例最高。在抽取缺陷代碼信息過程中，需要在缺陷數(shù)據(jù)庫中覆蓋代碼倉庫的項目基本信息，例如存儲庫名稱、描述、創(chuàng)建日期、最后推送日期、主頁、編程語言、分支數(shù)和星數(shù)等指標(biāo)，這些信息可作為過濾數(shù)據(jù)的參數(shù)，例如星數(shù)大小是關(guān)注項目成熟度的一個重要評判指標(biāo)，即星數(shù)越大的項目，成熟度越高。2.1.4缺陷代碼提取一般來說，只要修復(fù)了開源代碼漏洞，CVE描述記錄就會包含存儲庫的統(tǒng)一資源定位符（UniformResourceLocator，URL），利用抽取到的缺陷修復(fù)提交時生成的哈希和地址信息，通過git即可在本地克隆開源代碼項目，并根據(jù)哈希信息抽取修復(fù)之前和之后的代碼信息，這些信息包括缺陷修復(fù)時所涉及的代碼文件和代碼片段。其中提交信息中的每個條目可能與一個或多個CVE相關(guān)聯(lián)。提交的信息還包括作者、時間和日期、提交的描述消息等內(nèi)容。與缺陷相關(guān)的文件信息主要包含更改前后的文件內(nèi)容，以及在git提交過程中生成的diff信息。此外，還需要收集一些元數(shù)據(jù)，例如文件名、新舊路徑、修改類型（即添加、刪除、修改或重命名）、在該文件中添加或刪除的行數(shù)、代碼行數(shù)變化等。提取修改后的代碼片段，與抽取文件級別的更改過程相似，利用git工具抽取代碼片段的變更信息。除代碼外，涉及的數(shù)據(jù)信息，例如片段所在的方法名稱、其簽名性質(zhì)、參數(shù)、方法的開始行和結(jié)束行、代碼行數(shù)等作為方法元數(shù)據(jù)信息也會被抽取出來。為了更好地識別文件和代碼片段使用的具體編程語言信息，識別過程通過linguist[8]來檢測給定代碼內(nèi)容中使用的實際編程語言。2.2缺陷數(shù)據(jù)索引流程提取缺陷代碼后，需要對缺陷數(shù)據(jù)加工處理，存入數(shù)據(jù)庫中，形成缺陷代碼知識庫，供查詢模塊使用。缺陷數(shù)據(jù)索引流程如圖3所示。圖3缺陷數(shù)據(jù)索引流程2.2.1前端解析所有的代碼信息都要經(jīng)過編譯處理，用來從程序代碼中獲取函數(shù)信息并分析其詞法，但如果源代碼不完整或包含語法錯誤，將會影響整個解析過程。因此，為了保障分析的可靠性，采用antlr4完成代碼詞法解析，解析過程不需要代碼編譯構(gòu)建環(huán)境，能夠解析單個代碼文件，并且在解析過程中遇到語法錯誤時不會失敗，即使被測代碼不完整，也會兼容錯誤分析，保障解析順利通過。2.2.2預(yù)處理規(guī)范化整個數(shù)據(jù)索引和后邊的缺陷查詢過程均以代碼片段為基本單元，查詢過程中需要考慮代碼相似問題，如圖4所示，如下代碼可能會存在4種變種情況。圖4原始代碼片段Type-1：精確相似。被檢測代碼去掉空格、回車、注釋等與代碼無關(guān)信息后，與缺陷代碼保持一致。如圖5所示，與原代碼相比，代碼片段僅少了回車、空格信息。圖5Type-1代碼片段Type-2：重命名相似。與被檢測代碼中缺陷代碼相比，除了類型、標(biāo)識符、函數(shù)名、注釋和空格的修改，其他信息保持一致。如圖6所示，與原代碼相比，代碼片段中的方法名、參數(shù)類型做了部分修改，其他信息保持一致。圖6Type-2代碼片段Type-3：重組相似。即被檢測代碼與缺陷代碼相比，存在進一步的結(jié)構(gòu)修改（例如刪除、插入或重新排列語句）。如圖7所示，代碼片段增加了幾條新的語句。圖7Type-3代碼片段Type-4：語義相似。被檢測代碼與缺陷代碼在語法實現(xiàn)上完全不同，但實現(xiàn)的最終功能相同。如圖8所示，代碼片段實現(xiàn)的功能與圖4相同，但是語法表示方式已經(jīng)完全不同。圖8Type-4代碼片段Type-4語義相似目前很難通過代碼相似查找實現(xiàn)，故暫不在本研究的范圍之內(nèi)。本次只考慮Type-1、Type-2、Type-3型查詢。為了獲取更好的查找效果，需要對分詞的相似度進行規(guī)范化處理。在預(yù)處理階段，為了更準(zhǔn)確地找到缺陷代碼及其變種，需要從目標(biāo)源代碼中提取代碼塊并將其轉(zhuǎn)換為token序列，進行重組規(guī)范化，這里采用n-gram實現(xiàn)分詞重組。對于n而言，選擇一個大的數(shù)量原則上存在更長的重疊區(qū)域，并且攜帶更多單詞信息，精度會更高一些，但是會嚴(yán)重影響處理n-gram所需的內(nèi)存和磁盤I/O時間。相反，選擇小的n-gram允許更大的間隙和更好的匹配靈活性，并且需要更少的內(nèi)存和磁盤訪問時間，但也會導(dǎo)致檢索出缺陷代碼片段的概率更高，因此需要找到一個合適的n值，在查找速度和結(jié)果精度上得到平衡。首先定義一個包含a0、a1、a2及a3的數(shù)組：（1）原始表示a0：一個token序列，代表了原始代碼片段信息。（2）Type-1表示a1：包含來自原始代碼的標(biāo)記的n-gram的token序列，其為原始代碼token序列的組合。（3）Type-2表示a2：包含來自原始代碼的標(biāo)記的n-gram的token序列，其中原始代碼token序列中的標(biāo)識符、文字和類型標(biāo)記被代表標(biāo)記替換。（4）Type-3表示a3：包含來自原始代碼的標(biāo)記的n-gram的token序列，除字符{、}、[、]、(、)和；外，其他的全部按標(biāo)準(zhǔn)替換處理。標(biāo)點符號未標(biāo)準(zhǔn)化，因為它們對代碼結(jié)構(gòu)順序有著重要意義。通過調(diào)試分析，當(dāng)n值為4時，工具表現(xiàn)出了良好的性能。因此，當(dāng)預(yù)處理模塊中的4個代碼表示為a0時，則表示為原生分詞，不做任何排序組合；a1、a2和a3則表示選擇了4-gram。3個基于n-gram的表示(a1,a2,a3)是從原有的函數(shù)方法內(nèi)容中演變而來。通過預(yù)處理模塊的加工組合，將原有的代碼結(jié)構(gòu)進行了規(guī)范化，從而使其更適合代碼搜索。token規(guī)范化表示類型如表1所示，其中D代表數(shù)據(jù)類型，J代表類名，K代表關(guān)鍵字，P代表包，O代表運算符，S代表字符串文字，V代表數(shù)字，W代表變量。a2中所有標(biāo)識符、類型、數(shù)字和字符串文字分別被代表標(biāo)記W、D、V和S替換。a3中所有的分析都替換為它們各自的代表標(biāo)記形成規(guī)范化分詞序列。表1token規(guī)范化表示類型以圖9的代碼片段為例，規(guī)范化以后的分詞序列生成的內(nèi)容如圖10～圖13所示。圖9代碼片段樣例圖10a0規(guī)范化圖11a1規(guī)范化圖12a2規(guī)范化圖13a3規(guī)范化這種預(yù)處理能夠保障在搜索期間查詢的代碼關(guān)鍵信息與索引中代碼片段的表示相匹配。另外，在索引和查詢階段都會用到預(yù)處理規(guī)范化技術(shù)：在索引階段，搜索引擎為給定的代碼片段創(chuàng)建一個新文檔，并將4個表示放在文檔內(nèi)的單獨字段中，然后將文檔存儲在搜索索引中。在查詢階段，通過預(yù)處理將查詢內(nèi)容加工為一個組合查詢，組合包含4種關(guān)鍵字組成的子查詢序列。2.2.3缺陷數(shù)據(jù)索引數(shù)據(jù)存儲采用非關(guān)系索引數(shù)據(jù)庫工具Zinc，其具有索引功能，也是一種輕量級的搜索引擎，能夠滿足不同用戶的各種搜索需求，為所有類型的數(shù)據(jù)提供近乎實時的搜索和分析。對于結(jié)構(gòu)化或非結(jié)構(gòu)化的文本、數(shù)字?jǐn)?shù)據(jù)及地理空間數(shù)據(jù)，都能夠以快速搜索的方式高效地存儲和索引數(shù)據(jù)。建立缺陷數(shù)據(jù)索引的過程主要是對提取的開源代碼數(shù)據(jù)信息進行加工處理。整個流程為：將預(yù)處理加工過的規(guī)范化序列存儲到Zinc數(shù)據(jù)庫中，Zinc會生成反向索引，索引包括一組在document中出現(xiàn)的唯一單詞及單詞所出現(xiàn)的位置。索引建好后，可以通過Zinc所支持的文件和方法兩種類型的代碼完成查詢，對于完整的代碼文件，將代碼文件序列化后，以a0方式存入到數(shù)據(jù)庫中。對于文件中的方法，預(yù)處理后生成4種規(guī)范化標(biāo)識表示，這些規(guī)范化表示可以捕獲不同級別的代碼結(jié)構(gòu)，能夠有效地識別出缺陷代碼和缺陷變種。2.3缺陷代碼搜索缺陷代碼搜索主要利用分詞規(guī)范化和搜索引擎自身的索引查詢功能來搜索代碼中是否存在缺陷信息，在缺陷知識庫中搜索通過預(yù)處理后生成的關(guān)鍵字信息，并利用分詞規(guī)范化來提高代碼缺陷搜索的精度和相似匹配的靈活性。缺陷代碼搜索如圖14所示。圖14缺陷代碼搜索當(dāng)用戶提交待查詢的代碼后，首先對代碼進行詞法解析和預(yù)處理，這個過程與索引階段采用相同的方式。預(yù)處理結(jié)束后，一個序列化后的代碼查詢序列被發(fā)送到預(yù)處理模塊，生成4種查詢關(guān)鍵字，利用Zinc檢索功能，通過關(guān)鍵字檢索組合缺陷庫中的索引信息，匹配命中信息，并將最后的結(jié)果報告返回給用戶。3實驗本文通過搜索技術(shù)實現(xiàn)了一種開源代碼缺陷識別系統(tǒng)，通過一個實例來驗證系統(tǒng)的有效性。在大多數(shù)情況下，各種Linux發(fā)行版默認(rèn)提供的內(nèi)核都運行穩(wěn)定，但有些時候必須重新構(gòu)造和定制內(nèi)核來滿足實際需求，例如，系統(tǒng)中加入了當(dāng)前內(nèi)核不支持的或者尚未啟用相應(yīng)功能的硬件，或者物聯(lián)網(wǎng)設(shè)備操作系統(tǒng)、Android移動操作系統(tǒng)等都需要完成Linux系統(tǒng)的定制遷移。Linux各種主要發(fā)行版本中由供應(yīng)商提供的內(nèi)核往往明顯落后于最前沿的技術(shù)，而且它們的更新很不及時，這就導(dǎo)致系統(tǒng)中可能存在既有的安全風(fēng)險。CVE-2016-5195[9]是LinuxKernel中的條件競爭漏洞，攻擊者可以利用Linux內(nèi)核中的寫入復(fù)制技術(shù)中存在的邏輯漏洞完成對文件的越權(quán)讀寫。具體細節(jié)為：Linux內(nèi)核的內(nèi)存子系統(tǒng)在處理寫入復(fù)制（Copy-on-Write）時產(chǎn)生了競爭條件（RaceCondition）。惡意用戶可利用此漏洞來獲取高權(quán)限，對只讀內(nèi)存映射進行寫訪問。競爭條件是指任務(wù)執(zhí)行順序異常，可導(dǎo)致應(yīng)用崩潰，或令攻擊者有機可乘，進一步執(zhí)行其他代碼。攻擊者可利用這一漏洞提升目標(biāo)系統(tǒng)權(quán)限，甚至可能獲得root權(quán)限、代碼，如圖15所示。圖15CVE-2016-5195缺陷代碼Linux發(fā)行版本，如紅帽、Debian和CentOS，已經(jīng)發(fā)布了更新來解決內(nèi)核上存在的問題，但是很多由公司維護的移動操作系統(tǒng)卻沒有更新該內(nèi)核漏洞。使用本文提出的源代碼安全漏洞挖掘技術(shù)分析Android7.0、Andr