一種高效率的主動式漏洞挖掘平臺

聶黎生 李欣 李小紅

摘 要： 軟件測試的漏洞發(fā)掘技術(shù)在快速擴(kuò)展的互聯(lián)網(wǎng)軟件數(shù)量需求下，其存在效率低下，適應(yīng)測試環(huán)境的能力不強(qiáng)以及對軟件外部代碼的跟蹤能力弱等問題。在這種情形下，開發(fā)了一種主動式的多漏洞挖掘式數(shù)據(jù)平臺（MLIIMP）。一方面，該平臺能夠主動觸發(fā)軟件測試系統(tǒng)在運行時的位置漏洞；另一方面，系統(tǒng)在引入路徑搜索時還插入了新的函數(shù)模型，該模型的作用是保障符號傳播性能的大幅提升。漏洞測試結(jié)果表明這種平臺在進(jìn)行漏洞挖掘方面的效率有較大優(yōu)勢。

關(guān)鍵詞： 漏洞發(fā)掘； 挖掘效率； MLIIMP； 漏洞約束； 路徑搜索

中圖分類號： TN911?34； TP311 文獻(xiàn)標(biāo)識碼： A 文章編號： 1004?373X（2016）09?0093?06

Abstract： Under the demands of fast extended Internet software quantity， the vulnerability mining technology for software testing has the disadvantages of low mining efficiency， poor tracking ability for the software′s external code and poor adaptation ability for test environment. For the above problems， the many loopholes initiative integrated mining platform （MLIIMP） was developed. The platform can initiatively trigger the position loophole when the software testing system is running. The new function model is inserted when the path search is introduced into the system， which can greatly improve the symbols propagation performance. The vulnerability test results show that the platform has a great advantage to improve the vulnerability mining efficiency.

Keywords： vulnerability mining； mining efficiency； MLIIMP； loophole constraint； path search

0 引 言

軟件測試需求量在IT行業(yè)的快速發(fā)展勢頭下與日俱增，測試效率的保障和測試性能的提升也越來越受到使用者的關(guān)注。而對于軟件測試本身來看，漏洞的發(fā)掘是其主要測試目標(biāo)，行業(yè)內(nèi)的從業(yè)者和學(xué)者專家對該相關(guān)技術(shù)進(jìn)行了積極的研究 [1?2]。在眾多的技術(shù)研究中，動態(tài)符號技術(shù)因其獨特的優(yōu)勢，在漏洞發(fā)掘中處于研究的焦點之一。

動態(tài)符號技術(shù)相對發(fā)展較快，能夠?qū)Ρ粶y對象的測試動態(tài)過程進(jìn)行數(shù)據(jù)量化的記錄，進(jìn)而為后期分析漏洞挖掘過程及效果提供智力支撐和數(shù)據(jù)來源。相比于另一種靜態(tài)的分析過程，動態(tài)符號的優(yōu)勢十分明顯，分析結(jié)果更加精確可信 [3?5]。黑盒測試的方法曾經(jīng)在代碼測試技術(shù)上風(fēng)靡一時，基于動態(tài)符號技術(shù)的軟件測試具有更高的代碼覆蓋率，分析效果真實可信[6?7] 。而眾多普通的單路徑測試技術(shù)則只能發(fā)掘出該路徑上的漏洞[8?9]，而動態(tài)符號方式則完全打破了此種方式，其核心關(guān)鍵技術(shù)實現(xiàn)了多條測試路徑的并行檢測，以期達(dá)到發(fā)掘更多漏洞的效果 [10?11]。但新技術(shù)的出現(xiàn)依然伴隨著很多缺陷，主要可以從以下幾個角度來說明：一是觸發(fā)挖掘的形式仍然是被動的，不能對多變的測試環(huán)境及時做出響應(yīng) [12]；二是檢測功能相對而言變得更窄的測試功能適用范圍，對測試中需要的多種功能同時檢測的需求一般不能直接滿足；三是漏洞發(fā)掘的路徑層面存在較多的不足之處；四是一旦出現(xiàn)外部碼，測試環(huán)境與程序需求之間不能得到順暢傳輸。

為了避免上述問題，本文對動態(tài)符號執(zhí)行狀態(tài)西阿德數(shù)據(jù)挖掘進(jìn)行了新的開發(fā)和設(shè)計，形成了一個優(yōu)化的多漏洞主動挖掘平臺。該平臺的特征是能夠同時運行多條搜索信息路徑，實現(xiàn)對軟件的多維漏洞檢測；其次其優(yōu)勢體現(xiàn)在主動式搜索漏洞數(shù)據(jù)，運行搜索方式發(fā)生了改變。以上兩點均從軟件內(nèi)部的優(yōu)勢來說明，關(guān)鍵是當(dāng)面對外部碼需要檢測的情形時，該平臺還可以利用檢測器手段對漏洞進(jìn)行跨界檢索分析，擴(kuò)展范圍較大。最后，本文針對路徑搜索的方式進(jìn)行了新的設(shè)計，用來避免相同路徑的無效執(zhí)行，提升了數(shù)據(jù)挖掘效率。

1 MLIIMP的設(shè)計與實現(xiàn)

本節(jié)主要展示MLIIMP（Many Loopholes Initiative Integrated Mining Platform）的代碼設(shè)計過程，并將核心代碼部分予以直接展示，沒有采取偽代碼形式，旨在方便研究人員直接借鑒使用。

1.1 主動式漏洞發(fā)掘

在嵌入式研究行業(yè)內(nèi)，漏洞發(fā)掘技術(shù)的被動模式由來已久，本文設(shè)計的MLIIMP首要便打破了常規(guī)的被動形式改為主動觸發(fā)漏洞。主動觸發(fā)的形式需要在測試過程中進(jìn)行特定條件的設(shè)置，以條件運行來觸發(fā)漏洞[13]。

為了實現(xiàn)對可變漏洞的深入全面發(fā)掘，MLIIMP引入了漏洞約束的概念，并將約束模型化。本平臺中的約束并不具有隨機(jī)生成的特征，其為固定的幾種可選方式，相差較小。這種約束的設(shè)定是為了實現(xiàn)程序路徑的直接漏洞檢測，具體的代碼格式如下：

由上述代碼分析，若變量[x]能夠滿足約束要求[x！=2∧x<0∨x>3]時，代碼中的語句6被觸發(fā)漏洞。該漏洞觸發(fā)的前提是具備普通約束條件[x！=2]，如果約束具備則路徑運行能實現(xiàn)[1→2→3→5→6]，該運行路徑上的約束漏洞條件是[x<0∨x>3]，滿足上述約束條件，漏洞不可避免的觸發(fā)。

將漏洞發(fā)掘被動式改變?yōu)橹鲃有问?，需要利用MLIIMP實現(xiàn)實時監(jiān)控。對程序運轉(zhuǎn)測試過程進(jìn)行控制，一旦出現(xiàn)可能的漏洞觸發(fā)時，將約束條件引入到實測路徑，并利用平臺自帶功能實現(xiàn)標(biāo)記。這時的約束不同于常規(guī)約束，MLIIMP的自檢測剛好能實現(xiàn)二者的區(qū)別劃分和分類。對路徑進(jìn)行探究的過程中，約束條件沒有被否定是因為該約束并不是表達(dá)分支小程序段，其功能發(fā)生了本質(zhì)轉(zhuǎn)變。

1.2 漏洞檢測器

漏洞發(fā)掘的關(guān)鍵之一是漏洞檢測器的個性化，本文所提MLIIMP能夠?qū)崿F(xiàn)眾多類型開發(fā)，受文體所限，以下對其中四種作簡要闡明。

1.2.1 數(shù)組越界檢測器

數(shù)組越界檢測器是對數(shù)組發(fā)生越界后的漏洞進(jìn)行檢測分析，仍以1.1節(jié)中的代碼為例，語句6發(fā)生錯誤時便可以用該檢測器測得。

數(shù)組越界檢測的關(guān)鍵技術(shù)有三個方面的內(nèi)容：一是實現(xiàn)符號索引跟蹤，即是構(gòu)建一個索引實現(xiàn)符號在變量與數(shù)組傳播中的實施追蹤和記錄比對；二是檢測器能夠為數(shù)組實施操作識別；三是數(shù)組的界限需要進(jìn)行常規(guī)的檢測分析獲得，分析包含識別、界限檢測兩步。

為了詳細(xì)說明檢測器的運行過程，將其運行劃分為三個層面的步驟：一是實現(xiàn)路徑追蹤，主要通過監(jiān)控符號傳播的路徑來實現(xiàn)；第二步，發(fā)現(xiàn)疑似符號時，主動查詢當(dāng)前數(shù)組的范圍，對查詢結(jié)果進(jìn)行分析后獲得數(shù)組的界限情況。利用得到的界限情況設(shè)定漏洞約束條件，并將約束導(dǎo)入其間跟蹤繼續(xù)運行。新的路徑形成可以由以下公式進(jìn)行計算獲得：

在上述代碼中，語句3和5的表達(dá)出現(xiàn)了邏輯性錯誤，3的直接規(guī)定是size被定義為符號整數(shù)。而同樣的表達(dá)定義在語句5中重復(fù)出現(xiàn)，且這時的定義變?yōu)榱藷o符號整數(shù)，這樣前后矛盾的語句說明，將會直接出現(xiàn)內(nèi)存分配層面的邏輯錯誤，觸發(fā)系統(tǒng)運行漏洞。

函數(shù)參數(shù)錯誤檢測器的基本運行步驟可以視作兩個關(guān)鍵性流程：第一步是實現(xiàn)路徑追蹤，主要通過監(jiān)控符號傳播的路徑來實現(xiàn)；緊接著，對待測函數(shù)執(zhí)行插莊動作，使得待測函數(shù)一旦被調(diào)用則會自動觸發(fā)函數(shù)參數(shù)錯誤的約束條件，主動觸發(fā)漏洞約束。

1.3 函數(shù)模型

為了確保符號能夠準(zhǔn)確的執(zhí)行下去，本平臺中對眾多的外部函數(shù)預(yù)設(shè)了實施模型，這樣處理后的追蹤效果明顯提升，跟蹤符號傳播的任務(wù)更易實現(xiàn)。

MLIIMP函數(shù)模型常見于面向字符串的操作，這些內(nèi)存操作方式多樣，通常可劃分為以下memcpy，memset，strcat，strncpy，strcpy等形式。為了更好地實現(xiàn)執(zhí)行過程的再現(xiàn)，列舉出新的函數(shù)實例來分析獲得。進(jìn)行符號化的動態(tài)執(zhí)行時，函數(shù)程序一般在調(diào)用初始時不會出現(xiàn)符號化的直接特征，如strncpy（t，s，2）函數(shù)原始的緩沖目標(biāo)區(qū)間表示為非符號的t，而源緩沖則用符號化的形式表現(xiàn)，如[i1]與[i2，]此時的源緩沖還能用[s]替代描述。函數(shù)模型的分析結(jié)果是，性質(zhì)不是符號的[t]將會被執(zhí)行為符號參數(shù)，這樣的運行將會觸發(fā)符號參數(shù)錯誤的漏洞。在外部函數(shù)調(diào)用時，MLIIMP的處理流程較繁瑣，圖1為處理流程詳細(xì)步驟。

通過圖1可以看出，測試時一旦應(yīng)用到外部調(diào)用的情況，本平臺將會首先獲取外部函數(shù)對應(yīng)功能的函數(shù)名稱，獲取方式由API形式得到。緊接著，函數(shù)模型會在該名稱的指引搜索下被找到，若不存在對應(yīng)函數(shù)的實體程序，將會觸發(fā)該測試函數(shù)的對應(yīng)功能，若存在，則會對外部程序函數(shù)體深入檢測，進(jìn)行路徑的傳輸和追蹤。

1.4 優(yōu)化路徑搜索方法

MLIIMP的優(yōu)化路徑較多，搜索的方式也很多，多對多的開發(fā)形式可以有效避免資源浪費和搜索不徹底的情形發(fā)生。本搜索路徑優(yōu)化的基本原理是：第一，否定漏洞的約束條件；第二，若路徑指令多或者函數(shù)的優(yōu)先級較高時，將會在路徑執(zhí)行中獲得優(yōu)先運行的權(quán)限。下面將詳細(xì)描述路徑搜索算法，即Expand Execution函數(shù)，Symbolic Execution 函數(shù)以及Score函數(shù)。

上述語句14實現(xiàn)了對模式是否存在的判定，進(jìn)而在第15條語句中進(jìn)行調(diào)動的直接說明。如果指令需要數(shù)據(jù)進(jìn)行預(yù)設(shè)，此時的函數(shù)調(diào)用功能由input Symbolization調(diào)用和測試，進(jìn)一步實現(xiàn)參數(shù)的符號化表達(dá)。符號化成功后的指令如果在傳輸中需要調(diào)用，則采用symPropagation函數(shù)的相關(guān)功能實現(xiàn)。

此外，對于上述代碼中所示的Score函數(shù)。該執(zhí)行函數(shù)的一個關(guān)鍵特點是設(shè)定了depth，且將初始化數(shù)值設(shè)為0 ，該處理方式旨在避免求解的重復(fù)進(jìn)行，一旦關(guān)鍵函數(shù)在前述某個環(huán)節(jié)已經(jīng)進(jìn)行過求解運算，則在調(diào)用時會優(yōu)先考慮計算結(jié)果，并直接應(yīng)用。即便不能直接應(yīng)用，也可以只進(jìn)行增量化計算，確保節(jié)約運行時長，提升效率。

同樣地，其轉(zhuǎn)化功能也包含在程序體中，本例從語句6開始實施，對應(yīng)的將各編號種類進(jìn)行處理，編號表示為[i。]語句7執(zhí)行條件跳轉(zhuǎn)，語句8判斷是否需要跳轉(zhuǎn)。判斷方法是：若數(shù)值與其符號之間相關(guān)則出現(xiàn)depth累加計算。運行到語句13時，測試已經(jīng)獲得了漏洞出現(xiàn)的類型和特征數(shù)值，并利用語句14計算分值和各分值的權(quán)重（這個權(quán)重由漏洞的嚴(yán)重程度確定）。最終的分?jǐn)?shù)在語句16中獲得，并對應(yīng)輸出。

2 實驗與分析

本節(jié)主要介紹對平臺效果的實驗性檢驗，實驗結(jié)果和分析如下詳述。

2.1 MS06?001漏洞測試

常用于圖像存儲格式的WMF（Windows Meta File）形式被引入到MS06?001漏洞測試中。漏洞測試的格式具備較多的數(shù)據(jù)結(jié)構(gòu)類型，其中WMFRECORD的結(jié)構(gòu)特征對GDI格式的函數(shù)是否調(diào)用發(fā)揮了決定性作用。該結(jié)構(gòu)的后8位數(shù)據(jù)常視作索引數(shù)值大小。第9位字節(jié)存儲的數(shù)值表示了字節(jié)數(shù)量。程序會自動執(zhí)行0x90開始的全部代碼?？梢姙榱擞|發(fā)該約束條件下的漏洞，需要將第9字節(jié)處設(shè)定為制定的代碼值，即為0x16。只有在該種設(shè)定下才可以實現(xiàn)漏洞的觸發(fā)，具體過程如圖2所示。

黑盒測試技術(shù)不容易觸發(fā)MS06?001的漏洞，原因如下：考慮到該漏洞觸發(fā)的直接約束條件，首先第5個字節(jié)是0x26的觸發(fā)幾率為[1256，]同樣的，第9個字節(jié)是0x16的觸發(fā)幾率是[1256；]這些海量測試后的幾率顯示該技術(shù)同時滿足以上兩個條件的前提下，出現(xiàn)漏洞觸發(fā)的幾率僅僅為[165 536。]這個數(shù)值只是理論計算的結(jié)果，實踐中考慮到硬件以及實際運行情況，這種漏洞觸發(fā)的幾率往往比[165 536]還要低得多。

與傳統(tǒng)算法相比，以上MLIIMP在實測時消耗了較短的檢測時間，在較少的實驗資源前提下即實現(xiàn)了MS06?001漏洞的成功觸發(fā)。實驗結(jié)果顯示DEEPTH數(shù)值是906，表明約束量約為906個，同時在該約束量影響下，執(zhí)行的指令條數(shù)為1 763 456條，實現(xiàn)了14 581個字節(jié)的符號化需求和數(shù)值輸入。本次實驗用MLIIMP測試372例實驗案例。一共實現(xiàn)觸發(fā)次數(shù)為47次，觸發(fā)時的運行平均深度為72。這個平均深度表明漏洞MS06?001多發(fā)生在淺路徑之上。

2.2 CVE?2010?0188漏洞測試

與MS06?001漏洞測試不同，CVE?2010?0188漏洞的影響范圍更廣，程度更深，版本涉及面更廣。如Adobe Reader，Adobe Acrobat等均易受到漏洞侵襲。以上兩款軟件極易因文本漏洞而受到攻擊，本質(zhì)上說，PDF的格式特征決定了其復(fù)雜的后臺程序容易存在未知文本漏洞，且隨著每一次的升級和變化均可能造成新漏洞的擴(kuò)大。利用漏洞進(jìn)行文本攻擊，可以通過攻擊者以誘導(dǎo)形式進(jìn)行遠(yuǎn)程的控制，實現(xiàn)文本攻擊的惡意目的。

TIFF文件格式是文本攻擊的直接載體，分析其解析過程可以獲得前述兩大漏洞的存在具有相似的地方，除開屬性有所差異外，二者為同源條件下的不同漏洞表現(xiàn)形式。其實質(zhì)是記錄了當(dāng)前12個字節(jié)的目錄項數(shù)據(jù)以及詳細(xì)的數(shù)據(jù)結(jié)構(gòu)。

標(biāo)牌信息為0x150，具體的長度為數(shù)值2，類型表達(dá)為short。相關(guān)的偏移信息用符號Dot Range[1]或者Dot Range[0]表示。以上均處于TIFF的核心地位中。如果出現(xiàn)了新的長度，則這種情況必將導(dǎo)致異常運行，漏洞觸發(fā)的可能性增加。有意識的對長度值進(jìn)行限制，另一方面由組織編寫植入了惡意代碼形式，這些將會使得Libtiff的緩沖區(qū)發(fā)生明顯的數(shù)據(jù)溢出，惡意代碼運行將不受限制。

對于以上特點，本平臺MLIIMP將被動觸發(fā)的約束條件獲取后，主動導(dǎo)入約束邊界，將漏洞發(fā)掘的過程變?yōu)橹鲃颖O(jiān)測。本次測試工作耗時超過12 h，最終測試獲得的漏洞案例分別為第93，107。以上兩次測試分別觸發(fā)了Adobe Reader 9.3，Adobe Acrobat 9.3兩個不同閱讀器的漏洞約束。海量測試數(shù)據(jù)在acrobe和reader兩者上的成功測試用例數(shù)分別高達(dá)923以及854個。測試過程的輸入符號化總量分別達(dá)到97 899以及95 367個。測試后的平均路徑深度結(jié)果是12 151和11 936。

本文中對MLIIMP的測試表明（具體如表1所示），其實現(xiàn)正常檢測效果的時間較短，內(nèi)嵌的文本測試算法相對優(yōu)化，配合MLIIMP獨特的多路徑搜索功能以及主動的約束條件引入，以上均是該數(shù)據(jù)挖掘平臺的優(yōu)勢所在，對所有測試用例的測試速度效果提升明顯。

3 結(jié) 論

本文基于動態(tài)符號的漏洞發(fā)掘技術(shù)實現(xiàn)了具有新特征的MLIIMP測試平臺。該系統(tǒng)已經(jīng)成功實現(xiàn)四類漏洞的檢測和判定，總體說來，MLIIMP的優(yōu)勢主要有：漏洞檢測器種類多，發(fā)掘方式由被動變?yōu)橹鲃樱窂剿阉髯兊酶佣鄻踊揖珳?zhǔn)率提升，另外，其采用的函數(shù)模型提供了對外部程序追蹤的基礎(chǔ)。詳細(xì)闡述為，MLIIMP并不直接否定約束，而是主動設(shè)置漏洞約束并引入到路徑搜索的過程，同時為了節(jié)約搜索時間，本次開發(fā)還設(shè)置了避免重復(fù)搜索的功能函數(shù)，提升了漏洞測試效率，大大減少了測試時長。

雖然以上開發(fā)結(jié)果顯示本系統(tǒng)效果優(yōu)良，但對于因為長度設(shè)定后引發(fā)的數(shù)據(jù)緩沖區(qū)溢出測試不明顯，所以針對該漏洞的開發(fā)是本平臺需要改進(jìn)的方向。

參考文獻(xiàn)

[1] SUN H， ZENG Q K. Research on integer?based vulnerabilities： security model， detecting methods and real?world cases [J]. Journal of software， 2015， 26（2）： 413?426.

[2] 邢玉鳳.二進(jìn)制代碼的漏洞挖掘技術(shù)研究[J].計算機(jī)測量與控制，2014，22（12）：4111?4114.

[3] 趙躍華，闞俊杰.基于符號執(zhí)行的測試數(shù)據(jù)生成方法的研究與設(shè)計[J].計算機(jī)應(yīng)用與軟件，2014，31（2）：303?306.

[4] 趙剛，宋健豪.基于系統(tǒng)調(diào)用時間特征的異常行為智能檢測系統(tǒng)[J].計算機(jī)應(yīng)用與軟件，2015，32（4）：309?313.

[5] CSALLNER C， SMARAGDAKIS Y. Check ′n′ crash： combi?ning static checking and testing [C]// Proceedings of the 27th International Conference on Software Engineering. USA： ACM， 2005： 422?431.

[6] 劉春玲，雷海紅.黑盒測試用例設(shè)計方法研究[J].現(xiàn)代電子技術(shù)，2012，35（20）：46?48.

[7] TAHAT L H， VAYSBURG B， KOREL B， et al. Requirement?based automated black?box test generation [C]// Proceedings of 2001 25th Annual International Computer Software and Applications Conference. Chicago： IEEE， 2001： 489?495.

[8] NETHERCOTE N， SEWARD J. Valgrind： a framework for heavyweight dynamic binary instrumentation [C]// Proceedings of 2007 ACM SIGPLAN Conference on Programming Language Design and Implementation. USA： ACM， 2007： 89?100.

[9] 朱麗，李汪彪，蘇偉達(dá)，等.基于路徑覆蓋的嵌入式軟件動態(tài)測試研究[J].現(xiàn)代電子技術(shù)，2013，36（6）：63?65.

[10] 黃暉，陸余良，夏陽.基于動態(tài)符號執(zhí)行的二進(jìn)制程序缺陷發(fā)現(xiàn)系統(tǒng)[J].計算機(jī)應(yīng)用研究，2013，30（9）：2810?2812.

[11] 邵巳航，蘇亭，顧斌，等.基于過程間動態(tài)符號執(zhí)行的C語言測試框架[J].計算機(jī)工程與設(shè)計，2014，35（8）：2746?2751.

[12] GODEFROID P， LEVIN M， MOLNAR D. Automated whitebox fuzz testing [R]. US： Microsoft， 2006.

[13] GODEFROID P， LEVIN M Y， MOLNAR D. Active property checking [C]// Proceedings of the 7th ACM International Conference on Embedded Software. USA： ACM， 2007： 207?216.