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

聶黎生 李欣 李小紅

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

關鍵詞： 漏洞發掘； 挖掘效率； MLIIMP； 漏洞約束； 路徑搜索

中圖分類號： TN911?34； TP311 文獻標識碼： 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行業的快速發展勢頭下與日俱增，測試效率的保障和測試性能的提升也越來越受到使用者的關注。而對于軟件測試本身來看，漏洞的發掘是其主要測試目標，行業內的從業者和學者專家對該相關技術進行了積極的研究 [1?2]。在眾多的技術研究中，動態符號技術因其獨特的優勢，在漏洞發掘中處于研究的焦點之一。

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

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

1 MLIIMP的設計與實現

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

1.1 主動式漏洞發掘

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

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

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

將漏洞發掘被動式改變為主動形式，需要利用MLIIMP實現實時監控。對程序運轉測試過程進行控制，一旦出現可能的漏洞觸發時，將約束條件引入到實測路徑，并利用平臺自帶功能實現標記。這時的約束不同于常規約束，MLIIMP的自檢測剛好能實現二者的區別劃分和分類。對路徑進行探究的過程中，約束條件沒有被否定是因為該約束并不是表達分支小程序段，其功能發生了本質轉變。

1.2 漏洞檢測器

漏洞發掘的關鍵之一是漏洞檢測器的個性化，本文所提MLIIMP能夠實現眾多類型開發，受文體所限，以下對其中四種作簡要闡明。

1.2.1 數組越界檢測器

數組越界檢測器是對數組發生越界后的漏洞進行檢測分析，仍以1.1節中的代碼為例，語句6發生錯誤時便可以用該檢測器測得。

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

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

在上述代碼中，語句3和5的表達出現了邏輯性錯誤，3的直接規定是size被定義為符號整數。而同樣的表達定義在語句5中重復出現，且這時的定義變為了無符號整數，這樣前后矛盾的語句說明，將會直接出現內存分配層面的邏輯錯誤，觸發系統運行漏洞。

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

1.3 函數模型

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

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

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

1.4 優化路徑搜索方法

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

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

此外，對于上述代碼中所示的Score函數。該執行函數的一個關鍵特點是設定了depth，且將初始化數值設為0 ，該處理方式旨在避免求解的重復進行，一旦關鍵函數在前述某個環節已經進行過求解運算，則在調用時會優先考慮計算結果，并直接應用。即便不能直接應用，也可以只進行增量化計算，確保節約運行時長，提升效率。

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

2 實驗與分析

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

2.1 MS06?001漏洞測試

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

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

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

2.2 CVE?2010?0188漏洞測試

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

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

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

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

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

3 結 論

本文基于動態符號的漏洞發掘技術實現了具有新特征的MLIIMP測試平臺。該系統已經成功實現四類漏洞的檢測和判定，總體說來，MLIIMP的優勢主要有：漏洞檢測器種類多，發掘方式由被動變為主動，路徑搜索變得更加多樣化且精準率提升，另外，其采用的函數模型提供了對外部程序追蹤的基礎。詳細闡述為，MLIIMP并不直接否定約束，而是主動設置漏洞約束并引入到路徑搜索的過程，同時為了節約搜索時間，本次開發還設置了避免重復搜索的功能函數，提升了漏洞測試效率，大大減少了測試時長。

雖然以上開發結果顯示本系統效果優良，但對于因為長度設定后引發的數據緩沖區溢出測試不明顯，所以針對該漏洞的開發是本平臺需要改進的方向。

參考文獻

[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].計算機測量與控制，2014，22（12）：4111?4114.

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

[4] 趙剛，宋健豪.基于系統調用時間特征的異常行為智能檢測系統[J].計算機應用與軟件，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] 劉春玲，雷海紅.黑盒測試用例設計方法研究[J].現代電子技術，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] 朱麗，李汪彪，蘇偉達，等.基于路徑覆蓋的嵌入式軟件動態測試研究[J].現代電子技術，2013，36（6）：63?65.

[10] 黃暉，陸余良，夏陽.基于動態符號執行的二進制程序缺陷發現系統[J].計算機應用研究，2013，30（9）：2810?2812.

[11] 邵巳航，蘇亭，顧斌，等.基于過程間動態符號執行的C語言測試框架[J].計算機工程與設計，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.