腳本語言執(zhí)行引擎的模糊測試技術(shù)綜述①

孫力立 武成崗 許佳麗 張培華 唐博文 謝夢瑤

(計(jì)算機(jī)體系結(jié)構(gòu)國家重點(diǎn)實(shí)驗(yàn)室(中國科學(xué)院計(jì)算技術(shù)研究所) 北京100190)

(中國科學(xué)院大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 北京100190)

0 引言

腳本語言[1]是一種解釋性語言。不同于C、C++等編譯型語言,腳本語言依賴于相應(yīng)的腳本語言執(zhí)行引擎解釋執(zhí)行。由于腳本語言的廣泛使用,其執(zhí)行引擎也被廣泛部署在各種軟硬件設(shè)備上。例如,瀏覽器、PDF 閱讀器中內(nèi)嵌有JavaScript 的執(zhí)行引擎,很多物聯(lián)網(wǎng)(Internet of Things,IoT)設(shè)備中也部署了Python、JavaScript 等腳本語言的執(zhí)行引擎[2]。

腳本語言執(zhí)行引擎具有代碼量龐大且邏輯復(fù)雜的特點(diǎn),這也使得其中難免包含軟件缺陷和漏洞。以部署在iOS 系統(tǒng)Safari 瀏覽器中的JavaScript 執(zhí)行引擎JavaScriptCore[3]為例,其包含42 萬行C/C++代碼,定義了近2 萬多個(gè)類/結(jié)構(gòu)體。引擎本身的復(fù)雜度使得開發(fā)者在軟件開發(fā)過程中難免引入軟件缺陷和漏洞。而且,一些語言自身也處于不斷演化的狀態(tài),因此,引擎中的軟件缺陷和漏洞是一個(gè)長期存在的問題。

引擎安全漏洞種類多樣,主要包括棧溢出、堆溢出、釋放后使用和越界訪問等常見的內(nèi)存安全破壞型漏洞,此外也包括類型混淆、競爭條件等邏輯型漏洞等。引擎漏洞具有良好的可利用性,攻擊者可以通過編寫腳本語言代碼,利用引擎漏洞并放大其安全危害,從而對目標(biāo)機(jī)器造成嚴(yán)重侵害。因此,腳本語言執(zhí)行引擎中的安全漏洞具有很高的安全影響。

鑒于腳本語言執(zhí)行引擎漏洞的危害性,安全人員一直在嘗試通過人工及自動(dòng)化方法挖掘漏洞,而模糊測試[4]技術(shù)正是一種有效的方法。模糊測試方法借助機(jī)器算力,自動(dòng)化地生成大量測試用例,交由被測應(yīng)用執(zhí)行。通過觀察被測應(yīng)用在執(zhí)行中有無異常,如發(fā)生崩潰等,測試工具可以發(fā)現(xiàn)被測應(yīng)用中潛藏的軟件缺陷。模糊測試是一種有效的漏洞挖掘方法,但將模糊測試應(yīng)用于腳本語言執(zhí)行引擎中的漏洞挖掘仍存在一些挑戰(zhàn)。首先,腳本語言執(zhí)行引擎的輸入文件需要符合文法規(guī)則和語義約束,傳統(tǒng)的測試用例生成方法難以滿足上述條件。其次,引擎的工作流覆蓋多個(gè)處理模塊,模糊測試需要設(shè)計(jì)合適的測試用例生成方法和變異策略才能實(shí)現(xiàn)對各模塊的測試,或是對某一模塊的深度測試。此外,面對引擎無窮大的樣本輸入空間,提升模糊測試的測試效率也是一大挑戰(zhàn)。針對上述挑戰(zhàn),目前已有較多工作提出了相應(yīng)的解決方法,并發(fā)展出一系列針對腳本語言執(zhí)行引擎的模糊測試工具的評價(jià)指標(biāo)。

本文對近年來出現(xiàn)的各種腳本語言執(zhí)行引擎的模糊測試技術(shù)進(jìn)行了分析及歸類,主要貢獻(xiàn)如下。

(1)梳理了自2012 年以來的國內(nèi)外針對腳本語言執(zhí)行引擎的模糊測試文獻(xiàn),詳細(xì)討論了該領(lǐng)域的研究現(xiàn)狀。

(2)總結(jié)了腳本語言執(zhí)行引擎模糊測試工具的常用的評估指標(biāo)和評估方法。

(3)分別從測試用例生成方式、聚焦的測試模塊和采用的研究手段3 個(gè)不同的角度對現(xiàn)有工作進(jìn)行劃分,闡述了該領(lǐng)域所存在的研究問題和現(xiàn)有的解決方案。

(4)總結(jié)了腳本語言執(zhí)行引擎的模糊測試技術(shù)當(dāng)前存在的研究挑戰(zhàn),分析了該領(lǐng)域未來具有發(fā)展?jié)摿Φ难芯糠较颉?/p>

1 背景知識(shí)

1.1 模糊測試

模糊測試技術(shù)利用算力,隨機(jī)生成大量且多樣的測試用例,交由被測應(yīng)用執(zhí)行。模糊測試工具觀測被測應(yīng)用的執(zhí)行過程有無異常,收集可觸發(fā)被測應(yīng)用崩潰的測試用例,交由安全分析人員進(jìn)行分析。依據(jù)對被測應(yīng)用分析程度的不同,模糊測試可分為黑盒、灰盒和白盒測試[5]。黑盒測試無需對被測應(yīng)用的任何了解,其直接生成隨機(jī)輸入作為測試用例。白盒測試需要全面了解程序的內(nèi)部結(jié)構(gòu),并且對所有邏輯路徑進(jìn)行測試?；液袦y試介于黑盒和白盒測試之間,其對被測應(yīng)用的內(nèi)部邏輯有部分了解。當(dāng)前最具代表性的模糊測試工具AFL[6](American Fuzzy Lop)就使用灰盒測試技術(shù)。由于腳本語言執(zhí)行引擎具有代碼量龐大、邏輯復(fù)雜的特點(diǎn),其模糊測試工具大多采用黑盒和灰盒測試。

1.2 腳本語言執(zhí)行引擎

腳本語言執(zhí)行引擎負(fù)責(zé)解釋執(zhí)行腳本語言代碼。其通常由解析器、中間表示生成器和解釋器模塊構(gòu)成,具體工作流圖如圖1 所示。腳本語言執(zhí)行引擎最前端的是解析器模塊,包括詞法分析器(Lexer)和語法解析器(Parser)[7]。解析器模塊通過詞法、語法分析,將腳本語言代碼轉(zhuǎn)為抽象語法樹(abstract syntax tree,AST)。隨后,中間表示生成器將抽象語法樹轉(zhuǎn)為中間表示,如字節(jié)碼。最后,解釋器模塊負(fù)責(zé)對字節(jié)碼逐一解釋執(zhí)行。為了提升執(zhí)行效率,一些腳本語言執(zhí)行引擎還引入了即時(shí)(just-intime,JIT)編譯器[8]模塊。對于解釋器模塊頻繁解釋執(zhí)行的字節(jié)碼,例如循環(huán)體或被頻繁調(diào)用的函數(shù)體,JIT 編譯器為其編譯生成實(shí)現(xiàn)相同語義功能的二進(jìn)制代碼,并存儲(chǔ)在內(nèi)存中。當(dāng)上述字節(jié)碼再次執(zhí)行時(shí),執(zhí)行引擎會(huì)將控制流跳轉(zhuǎn)到相應(yīng)的二進(jìn)制代碼執(zhí)行,而無需由解釋器解釋執(zhí)行。

圖1 腳本語言執(zhí)行引擎的通用工作流程

2 評價(jià)指標(biāo)

隨著腳本語言執(zhí)行引擎的模糊測試技術(shù)的發(fā)展,越來越多的模糊測試工具相繼出現(xiàn)。因此,需要有效的評估方法和評估指標(biāo)用以衡量測試工具的有效性和先進(jìn)性。本文總結(jié)了近年來腳本語言執(zhí)行引擎模糊測試工具所使用的評價(jià)指標(biāo),如表1 所示。在所有評估指標(biāo)中,測試工具所挖掘到的漏洞和缺陷數(shù)目是最為關(guān)鍵的評價(jià)指標(biāo)。此外,代碼覆蓋率、語法語義通過率和測試速度也是較為常見的測試指標(biāo)。

表1給出了一些代表性的腳本語言執(zhí)行引擎模糊測試工具的評測情況。其中,“-”表示無相應(yīng)實(shí)驗(yàn)數(shù)據(jù),“Y”表示有相應(yīng)實(shí)驗(yàn)數(shù)據(jù)?！叭毕?漏洞發(fā)現(xiàn)情況”列中給出了測試工具所發(fā)現(xiàn)的腳本語言執(zhí)行引擎的缺陷數(shù)目,括號(hào)中的是CVE 數(shù)目?！案采w率”列中給出了實(shí)驗(yàn)所使用的代碼覆蓋率評估粒度。其中,L代表行覆蓋率,F代表函數(shù)覆蓋率,E代表邊覆蓋率,B代表分支覆蓋率,BB代表基本塊覆蓋率?！巴ㄟ^率”列中,SYN 表示實(shí)驗(yàn)評測了語法通過率,SEM 表示實(shí)驗(yàn)評測了語義通過率。

表1 部分腳本語言執(zhí)行引擎模糊測試工具的評價(jià)情況

2.1 漏洞和缺陷數(shù)目

測試工具所發(fā)現(xiàn)的漏洞和缺陷的數(shù)目是評估該工具有效性的最關(guān)鍵的指標(biāo)。漏洞CVE 編號(hào)[24]和引擎廠商已確認(rèn)的錯(cuò)誤報(bào)告編號(hào)都可以作為模糊測試工具發(fā)現(xiàn)漏洞和缺陷的憑證。在測試工具收集到可觸發(fā)執(zhí)行引擎崩潰的測試用例后,研究人員可以向引擎開發(fā)團(tuán)隊(duì)提交錯(cuò)誤報(bào)告或漏洞報(bào)告。報(bào)告需附上可重現(xiàn)該錯(cuò)誤的腳本語言代碼,即PoC(proofof-concept)。之后,引擎開發(fā)者會(huì)判斷該錯(cuò)誤是否為軟件缺陷或漏洞,并對其進(jìn)行修復(fù)。對于存在安全危害的軟件缺陷,引擎廠商或研究人員可為其申請CVE 編號(hào),并發(fā)布漏洞公告。

鑒于腳本語言執(zhí)行引擎具有代碼量龐大、邏輯復(fù)雜的特點(diǎn),為了測試充分,模糊測試工具的測試時(shí)間通常以月為單位。測試時(shí)間較長的如文獻(xiàn)[13],可達(dá)450 d。測試時(shí)間最短的如文獻(xiàn)[19]僅耗時(shí)3 d。大多數(shù)相關(guān)工作的測試用時(shí)在30～90 d,如文獻(xiàn)[10,12,16,22]。其中,文獻(xiàn)[19]的測試用時(shí)之所以僅為3 d,是因?yàn)樵撓到y(tǒng)部署在大規(guī)模的機(jī)器集群上,集群的機(jī)器總核心數(shù)目是其他工作所用核心數(shù)目的百倍以上。

為了體現(xiàn)測試工具的先進(jìn)性,研究人員需要與其他測試工具進(jìn)行測試實(shí)驗(yàn)對比。但是,復(fù)現(xiàn)上述測試所需的時(shí)間代價(jià)很大。當(dāng)前的對比實(shí)驗(yàn)通常限制在一個(gè)更短的時(shí)間內(nèi)完成,例如文獻(xiàn)[10,22]中評估了24 h 內(nèi)不同模糊測試工具所發(fā)現(xiàn)的引擎缺陷數(shù)目。

2.2 代碼覆蓋率

代碼覆蓋率[25]是評估模糊測試工具有效性的另一重要指標(biāo)。高代碼覆蓋率說明測試工具能夠執(zhí)行到其他工具無法覆蓋到的代碼。而測試不充分的代碼中往往包含軟件缺陷,因此,高代碼覆蓋率也意味著有更多發(fā)現(xiàn)軟件缺陷的可能性。

代碼覆蓋率包含多種不同粒度的評估方式:行覆蓋率、基本塊覆蓋率、函數(shù)覆蓋率、分支覆蓋率、邊覆蓋率和路徑覆蓋率。行覆蓋率是指被測應(yīng)用在測試過程中所執(zhí)行到的代碼行數(shù)占源碼總行數(shù)的比例。其他覆蓋率的定義以此類推。在上述覆蓋率中,邊覆蓋率的使用較為常見,除了表1 中的文獻(xiàn),AFL 使用的也是邊覆蓋率。由于路徑爆炸問題[26],路徑覆蓋率在實(shí)際工作中極少被應(yīng)用,且通常使用所覆蓋到的路徑數(shù)目替代。雖然代碼覆蓋率的評估粒度多樣,但并沒有一個(gè)通用的最優(yōu)選擇[27],所以,不同工作按需選取合適的評估方式。雖然用代碼覆蓋率能否評估測試工具有效性一直存在爭議[28],但其仍然是一個(gè)不可或缺的評估指標(biāo)。

收集覆蓋率信息需要對編譯器進(jìn)行修改或配置。主流編譯器如Clang[29]和GCC[30]提供了一些命令行選項(xiàng)[31-32],支持在編譯源碼的同時(shí)插樁收集覆蓋率信息的代碼。此外,研究人員也可以使用定制的編譯器來實(shí)現(xiàn)覆蓋率信息的收集。

2.3 語法語義通過率

語法語義通過率是指能夠通過語法和語義檢查的測試用例數(shù)目占測試用例總數(shù)的比例,是評估引擎的模糊測試工具的一個(gè)重要指標(biāo)。較低的語法語義通過率意味著執(zhí)行引擎的執(zhí)行流僅僅局限在引擎前端,無法深入引擎后端的代碼邏輯。

當(dāng)測試用例中存在語法錯(cuò)誤時(shí),引擎執(zhí)行到解析器模塊便會(huì)報(bào)出該語法錯(cuò)誤并終止執(zhí)行。圖2(a)展示了一個(gè)JavaScript 的語法錯(cuò)誤[33]實(shí)例,由于正則表達(dá)式中沒有為“q”的標(biāo)志,因此執(zhí)行引擎檢測出語法錯(cuò)誤。如果測試用例通過了語法檢查,后續(xù)的解釋器模塊還會(huì)進(jìn)行語義檢查。對于存在語義錯(cuò)誤的情況,引擎也會(huì)及時(shí)報(bào)錯(cuò)并終止執(zhí)行。圖2(b)和圖2(c)分別展示了2 種不同的JavaScript 語義錯(cuò)誤實(shí)例。其中,圖2(b)中使用了未定義的變量a,因此執(zhí)行引擎檢測出引用錯(cuò)誤[34];圖2(c)中12 不是函數(shù)卻用作函數(shù)調(diào)用,因此執(zhí)行引擎檢測出類型錯(cuò)誤[35]。

圖2 JavaScript 語言的語法和語義錯(cuò)誤實(shí)例

通過解析執(zhí)行引擎在執(zhí)行測試用例過程中的輸出信息,可以判別出該測試用例是否觸發(fā)了語法語義錯(cuò)誤,以及具體的錯(cuò)誤類型。

2.4 測試速度

測試速度是指模糊測試工具在單位時(shí)間內(nèi)生成并執(zhí)行的測試用例的數(shù)量。測試速度并不是一個(gè)關(guān)鍵評價(jià)指標(biāo),因?yàn)闇y試速度的快慢和模糊測試工具的優(yōu)劣并非正相關(guān)。越是簡單的變異策略,如隨機(jī)字節(jié)變異,越能帶來很高的測試速度。但這種變異方式會(huì)導(dǎo)致很低的語法語義通過率,并不能帶來測試深度的提升。不過,一些工作(如文獻(xiàn)[11]等,見表1)還是在實(shí)驗(yàn)中對該指標(biāo)進(jìn)行了評測。

3 方法分類

本文從3 個(gè)角度對現(xiàn)有的腳本語言執(zhí)行引擎的模糊測試工作進(jìn)行劃分。如圖3 所示,從測試用例生成方式的角度可以分為基于生成和基于變異;從所聚焦的測試模塊的角度可以分為針對解析器、針對解釋器和針對JIT編譯器;從所采用的技術(shù)手段的角度可以分為傳統(tǒng)程序分析方法和機(jī)器學(xué)習(xí)方法。

圖3 腳本語言執(zhí)行引擎模糊測試技術(shù)分類

3.1 按生成方式劃分

3.1.1 基于生成

基于生成的方法無需初始種子文件,從頭開始生成符合語言文法的測試用例。最早的工作是2007 年的jsfunfuzz[9],其將JavaScript 代碼的文法規(guī)則硬編碼在程序中,在程序執(zhí)行中不斷推導(dǎo)文法規(guī)則,最后生成符合文法的測試用例。該方法能夠生成大量多樣的JavaScript 代碼,并發(fā)現(xiàn)了數(shù)百個(gè)引擎缺陷。但是,該方法也具有缺乏通用性的缺點(diǎn),且生成的測試用例難以滿足語義約束。GramTest[36]解決了通用性的問題。對于任何可用巴科斯范式(Backus-Naur form,BNF)表述文法規(guī)則的語言,該方法都可以生成符合文法約束的測試用例。具體實(shí)現(xiàn)如圖4 所示。圖中左側(cè)黑框內(nèi)是一個(gè)使用BNF表述的語言文法,其中,N 表示非終結(jié)符,T 表示終結(jié)符,R 表示該文法所包含的推導(dǎo)規(guī)則,S 表示文法推導(dǎo)的起始符號(hào)。圖中右側(cè)給出了從PROG 開始的一次隨機(jī)文法推導(dǎo)過程。推導(dǎo)過程依次選取推導(dǎo)規(guī)則(1)→(4)→(5)→(6)→(8),最終得到“a=1”這個(gè)滿足文法要求的字符串。這種基于文法推導(dǎo)規(guī)則的測試用例生成方法不僅被基于生成的方法[15]所使用,很多基于變異的工作[10,12,19,22]也采用該技術(shù)來生成變異所需的代碼片段。為了進(jìn)一步提升通用性,文獻(xiàn)[17]提出了一種通過測試自動(dòng)歸納文法規(guī)則的方法,從而使測試系統(tǒng)無需語言文法作為輸入。

圖4 基于文法推導(dǎo)規(guī)則的測試用例生成

上述方法所得到的測試用例雖然滿足文法約束,但難以滿足語義約束。測試用例在執(zhí)行中會(huì)觸發(fā)各種語義錯(cuò)誤[37],例如未定義的變量使用錯(cuò)誤、非預(yù)期的數(shù)據(jù)類型錯(cuò)誤等。因此,一些工作使用比文法規(guī)則更高級的概念來指導(dǎo)生成,從而在測試用例生成時(shí)考慮到語義信息的維護(hù)。FuzzIL[14]引入了自定義的中間表示語言,其在中間表示的層面進(jìn)行生成和變異。CodeAlchemist[18]引入了“代碼磚石”這一概念?！按a磚石”是由大量JavaScript 種子文件做語句級拆解而得到的代碼片段。其中不僅包含JavaScript 語句,還包含語句中所定值和使用的變量及這些變量的類型信息。

3.1.2 基于變異

基于變異的方法需要一批語法語義正確的初始種子作為輸入,通過對其進(jìn)行變異,生成測試用例。為了保證測試用例的語法正確性,基于變異的方法(如文獻(xiàn)[10-12,16,19,38])會(huì)依據(jù)文法,先將種子文件轉(zhuǎn)為抽象語法樹(AST),再在語法樹節(jié)點(diǎn)上做符合語法規(guī)則的變異。圖5 展示了在抽象語法樹上的語法子樹替換變異。圖5 表示的是“a=6*(7 +3)”對應(yīng)的抽象語法樹。通過將虛線框中的Literal子樹節(jié)點(diǎn)替換為另一個(gè)相同語法類型的子樹節(jié)點(diǎn),可以實(shí)現(xiàn)符合語法規(guī)則的子樹變異。

圖5 語法子樹替換變異

為了生成符合語義約束的測試用例,POLYGLOT[22]將語法樹進(jìn)一步轉(zhuǎn)為包含變量作用域、變量類型等語義信息的中間表示,之后對中間表示進(jìn)行變異。其變異策略不僅考慮到語法正確性,也維護(hù)了語義正確性。

基于生成的方法和基于變異的方法各有優(yōu)劣?；谧儺惖姆椒ㄋ玫降臏y試用例往往有更高的語法語義通過率,因?yàn)槠涫窃谠揪驼Z法語義正確的測試用例的基礎(chǔ)上做小范圍的變異。不過,基于變異的方法難以像基于生成的方法一樣,生成一些不符合人工編碼習(xí)慣,但又滿足語法規(guī)則的測試用例。此外,基于變異的方法還存在一大限制,即需要大量的初始種子以覆蓋各種語法結(jié)構(gòu)、內(nèi)建對象和內(nèi)建函數(shù)。當(dāng)前基于變異的方法通常使用執(zhí)行引擎和語言規(guī)范中自帶的測試集,以及從網(wǎng)上爬取腳本語言代碼,作為初始種子。

3.2 按測試模塊劃分

3.2.1 針對解析器

解析器模塊作為執(zhí)行引擎最前端的一個(gè)模塊,也是測試最為充分的一個(gè)模塊,但這并不意味著該模塊中就沒有軟件缺陷。一些腳本語言自身處于不斷演化的狀態(tài),需修改解析器以支持新增的語言特性。這些修改可能會(huì)引入軟件缺陷。另一方面,由于解析器模塊所接收的輸入通常是符合文法的,反而導(dǎo)致一些錯(cuò)誤處理相關(guān)的邏輯并未被充分測試。因此,針對解析器的模糊測試既應(yīng)覆蓋解析器中的正常處理邏輯,也應(yīng)覆蓋到各種錯(cuò)誤處理邏輯。

文獻(xiàn)[15,16]保留了AFL 中的變異策略,并在此基礎(chǔ)上引入了基于文法的化簡機(jī)制和變異策略?；谖姆ǖ淖儺惒呗钥梢陨蓾M足語法約束的測試用例,從而測試解析器中的正常處理邏輯。AFL 原生的比特翻轉(zhuǎn)、字節(jié)翻轉(zhuǎn)等變異策略,能夠生成大量不合文法、且難以人工構(gòu)造的測試用例,從而測試解析器的錯(cuò)誤處理邏輯。

3.2.2 針對解釋器

解釋器模塊位于解析器和字節(jié)碼生成器之后。為實(shí)現(xiàn)針對解釋器模塊的充分測試,需要模糊測試技術(shù)生成語法語義正確且多樣的測試用例。

對于正確性這一目標(biāo),文獻(xiàn)[9,10,12,15,16]使用文法規(guī)則指導(dǎo)測試用例的生成和變異(如3.1節(jié)所示)。但是,基于文法的生成/變異方法并不能保證語義的正確性。一些工作針對語義正確性提出了相應(yīng)的解決方法。例如,LangFuzz[10]使用變異點(diǎn)作用域下可用的變量名,修正變異所引入的未定義標(biāo)識(shí)符。POLYGLOT[22]將種子文件轉(zhuǎn)為中間表示,該中間表示不僅包含語法節(jié)點(diǎn)信息,也包含語義信息(數(shù)據(jù)的類型和作用域)。因此在變異中可以同時(shí)考慮到對兩者正確性的維護(hù)。文獻(xiàn)[39]針對函數(shù)調(diào)用進(jìn)行變異,其提出了一種函數(shù)參數(shù)類型的推斷方法,實(shí)現(xiàn)了對測試用例的精確變異。文獻(xiàn)[23]不僅采用了路徑敏感的變量識(shí)別方法,還使用了動(dòng)靜態(tài)方法實(shí)現(xiàn)對變量類型的準(zhǔn)確推導(dǎo)。此外,文獻(xiàn)[23]還提出了啟發(fā)式修復(fù)方法,利用測試用例執(zhí)行時(shí)獲得的語法或語義出錯(cuò)信息,指導(dǎo)對測試用例進(jìn)行語法和語義修復(fù)。

對于多樣性這一目標(biāo),大多數(shù)工作依靠初始種子來實(shí)現(xiàn)生成測試用例的語法語義多樣性。文獻(xiàn)[23]利用運(yùn)行時(shí)反射信息,獲取數(shù)據(jù)對象所包含的屬性和函數(shù),獲得語義多樣的變異素材。目前,尚未有相關(guān)工作提出語法語義多樣性的評估方法。不過,模糊測試的關(guān)鍵指標(biāo)是發(fā)現(xiàn)缺陷的數(shù)目。所以,也可以通過這一指標(biāo)來間接評估生成測試用例的多樣性。例如文獻(xiàn)[23]分別評測了SoFi_V(保留了和正確性相關(guān)的變異機(jī)制)與SoFi_D(保留了和多樣性相關(guān)的變異機(jī)制)的缺陷發(fā)現(xiàn)數(shù)目,以評估變異機(jī)制對測試效果的影響。除了運(yùn)行時(shí)反射信息,語言規(guī)范也可以指導(dǎo)生成語法語義多樣且正確的測試用例。文獻(xiàn)[21]利用JavaScript 語言規(guī)范生成針對內(nèi)建函數(shù)的測試用例。其從語言規(guī)范中抽取出內(nèi)建函數(shù)潛在的參數(shù)類型,并生成相應(yīng)的實(shí)參以觸發(fā)各種邊界條件。

3.2.3 針對JIT 編譯器

與解釋器不同,語言規(guī)范中并不定義JIT 編譯器的實(shí)現(xiàn)標(biāo)準(zhǔn)。不同的引擎廠商有著獨(dú)有的JIT 編譯優(yōu)化機(jī)制。JIT 編譯優(yōu)化機(jī)制復(fù)雜多樣,一些激進(jìn)的優(yōu)化策略在特殊的邊界情況下,可能帶來安全隱患。針對JIT 編譯器的模糊測試,需要生成的測試用例既可觸發(fā)JIT 編譯器工作,又可覆蓋各種優(yōu)化策略。

一種簡單的解決方法是使用模板。文獻(xiàn)[40]的模板中定義了循環(huán)體和被循環(huán)調(diào)用的函數(shù)。該代碼結(jié)構(gòu)可以觸發(fā)JIT 編譯器對循環(huán)中的函數(shù)進(jìn)行編譯優(yōu)化。同時(shí),通過對函數(shù)體內(nèi)的代碼進(jìn)行變異,可以使JIT 編譯器的輸入具有多樣性。從實(shí)驗(yàn)結(jié)果上看,該方法所生成的測試用例雖具有很高的JIT 成功率和JIT 覆蓋率,卻難以觸發(fā)JIT 編譯器中的軟件缺陷。一些工作雖并非針對JIT 編譯器進(jìn)行測試,但在JIT 編譯器的漏洞挖掘上卻取得了很好的效果。例如,FuzzIL[14]構(gòu)造出的測試用例具有復(fù)雜且不合常規(guī)的數(shù)據(jù)流和控制流,在挖掘JIT 編譯器的軟件缺陷和漏洞中也有很好的效果[41]。DIE[19]使用漏洞PoC 和回歸測試作為初始種子,并通過“方面-保存”的變異策略,使變異不會(huì)改變原有種子文件的控制流結(jié)構(gòu)和數(shù)據(jù)類型信息。DIE 的變異策略可以使原本可觸發(fā)JIT 編譯優(yōu)化的循環(huán)體或函數(shù)在迭代變異中得到保留,其中可以觸發(fā)某些特殊優(yōu)化策略的代碼也有一定概率不被破壞,其實(shí)驗(yàn)結(jié)果也證實(shí)了DIE 能夠發(fā)現(xiàn)JIT 編譯器中的軟件缺陷和漏洞。

3.3 按技術(shù)手段劃分

3.3.1 傳統(tǒng)程序分析方法

傳統(tǒng)的程序分析方法在腳本語言測試用例的自動(dòng)生成方面得到了普遍使用。其中,最為常用的技術(shù)是使用抽象語法樹表示測試用例,例如文獻(xiàn)[10-13,15,16,19]等。該方法借助語法解析器,將測試用例由字符串轉(zhuǎn)成抽象語法樹進(jìn)行存儲(chǔ)。這既可以實(shí)現(xiàn)對測試用例的語法正確性檢測,又為后續(xù)的語法子樹變異提供了素材。抽象語法樹雖然提供了語法信息,但缺少語義信息。文獻(xiàn)[19]在抽象語法樹的基礎(chǔ)上,對測試用例進(jìn)行變量的作用域分析和數(shù)據(jù)類型分析。作用域分析明確了各個(gè)變量的生命周期,數(shù)據(jù)類型分析明確了變量的類型。它們都為后續(xù)的變異或生成策略提供了合適的數(shù)據(jù)素材。此外,構(gòu)造中間表示也是一種常用的程序分析方法,常見的中間表示如三地址碼。使用中間表示來存儲(chǔ)測試用例,可以隱去測試用例中復(fù)雜的語法結(jié)構(gòu),更適合進(jìn)行語義分析。文獻(xiàn)[14,22]便是中間表示的典型應(yīng)用。使用程序分析方法對測試用例進(jìn)行分析,具有準(zhǔn)確性高、可操作性強(qiáng)的優(yōu)點(diǎn)。但該方法也具有依賴專家經(jīng)驗(yàn)和難以獲得通用性的缺點(diǎn)。

3.3.2 機(jī)器學(xué)習(xí)方法

機(jī)器學(xué)習(xí)作為當(dāng)下非常熱門的研究方向,其解決方法在很多領(lǐng)域都得到了成功應(yīng)用。文獻(xiàn)[13,42]利用統(tǒng)計(jì)學(xué)習(xí)方法指導(dǎo)測試用例生成。文獻(xiàn)[42]從大量樣本中學(xué)習(xí)出文法推導(dǎo)規(guī)則的概率模型,用來指導(dǎo)生成和樣本相似的語言樣例,從而確保語法語義的正確性。文獻(xiàn)[13]進(jìn)一步學(xué)習(xí)出上下文敏感的文法推導(dǎo)規(guī)則的概率模型,在該模型的指導(dǎo)下,可以生成語法語義正確且在樣本中較為罕見的語言樣例。文獻(xiàn)[20]和文獻(xiàn)[21]分別提出了使用神經(jīng)網(wǎng)絡(luò)語言模型和GPT-2 語言生成模型自動(dòng)生成的JavaScript 代碼的方法。機(jī)器學(xué)習(xí)方法的優(yōu)點(diǎn)在于具有良好的通用性、也無需應(yīng)用領(lǐng)域相關(guān)的先驗(yàn)知識(shí),缺點(diǎn)在于需要大規(guī)模的訓(xùn)練數(shù)據(jù),且生成代碼的語法語義正確性不夠高。

4 研究不足和未來趨勢

依據(jù)對現(xiàn)有研究成果的分析,腳本語言執(zhí)行引擎的模糊測試技術(shù)存在以下研究挑戰(zhàn)。

(1)反饋機(jī)制的設(shè)計(jì)

反饋機(jī)制對模糊測試工具的漏洞挖掘能力和執(zhí)行效率都有著至關(guān)重要的影響。當(dāng)前大多數(shù)模糊測試技術(shù)[6,43-44]所使用的反饋機(jī)制都是代碼覆蓋率反饋。而程序執(zhí)行狀態(tài)的另一組成部分——數(shù)據(jù),卻被長期忽視。不過,在最新的模糊測試研究中,一些工作[45-46]開始將數(shù)據(jù)狀態(tài)引入反饋機(jī)制,并取得了不錯(cuò)的漏洞挖掘效果。腳本語言執(zhí)行引擎內(nèi)部有著非常豐富的數(shù)據(jù)狀態(tài)。設(shè)計(jì)合適的數(shù)據(jù)相關(guān)的反饋機(jī)制指導(dǎo)腳本語言執(zhí)行引擎的模糊測試,是一個(gè)很有前景的研究方向。

(2)語言標(biāo)準(zhǔn)指導(dǎo)的模糊測試

為了確保不同引擎對腳本語言具有相同的解釋執(zhí)行結(jié)果,引擎廠商原則上應(yīng)嚴(yán)格遵循語言標(biāo)準(zhǔn),實(shí)現(xiàn)解釋器。語言標(biāo)準(zhǔn)作為腳本語言執(zhí)行引擎實(shí)現(xiàn)的依據(jù),也可以用于指導(dǎo)針對腳本語言執(zhí)行引擎的模糊測試。但當(dāng)前僅有少數(shù)工作利用語言標(biāo)準(zhǔn)指導(dǎo)測試,且利用程度并不充分。隨著自然語言處理、知識(shí)圖譜、知識(shí)推理等技術(shù)的發(fā)展,這些技術(shù)可以從語言標(biāo)準(zhǔn)中抽取出豐富的“基本事實(shí)”(ground truth),用以指導(dǎo)模糊測試。

(3)語義多樣性

現(xiàn)有工作在生成腳本語言測試用例時(shí),主要關(guān)注語法語義正確性,而缺少對語義多樣性的關(guān)注。當(dāng)前的技術(shù)主要依靠大量的初始種子文件來保障語義多樣性。如果種子文件中缺少某種內(nèi)建函數(shù)的調(diào)用,就無法生成包含該內(nèi)建函數(shù)的測試用例。針對生成測試用例的語義多樣性,設(shè)計(jì)合適的評估方法和變異機(jī)制,也是一個(gè)很有意義的研究方向。

5 結(jié)論

腳本語言執(zhí)行引擎的安全漏洞具有很高的安全危害和利用價(jià)值。通過模糊測試技術(shù)挖掘腳本語言執(zhí)行引擎的軟件缺陷和漏洞,是近年來的一個(gè)研究熱點(diǎn)。本文圍繞腳本語言執(zhí)行引擎的模糊測試技術(shù)的研究現(xiàn)狀進(jìn)行了梳理和分類,總結(jié)了當(dāng)前的評估指標(biāo),并從不同角度分析了現(xiàn)有工作關(guān)注的研究難點(diǎn)和采取的解決方案。此外,本文討論并總結(jié)了腳本語言執(zhí)行引擎模糊測試技術(shù)面臨的挑戰(zhàn)和發(fā)展趨勢,為后續(xù)研究提供了重要的參考價(jià)值。