◎侯 楓 趙 倩

(三門峽職業(yè)技術(shù)學(xué)院 信息傳媒學(xué)院，河南 三門峽 472000)

Android應(yīng)用程序輸入接口，只提供靜態(tài)權(quán)限檢查保護(hù)機(jī)制，不進(jìn)行輸入驗(yàn)證。若防范措施不嚴(yán)密，容易導(dǎo)致混淆代理漏洞（Confused Deputy Attack）和拒絕服務(wù)漏洞。如何挖掘Android環(huán)境下輸入驗(yàn)證漏洞是筆者主要討論的問題。

目前輸入驗(yàn)證漏洞挖掘通過先驗(yàn)知識(shí)，預(yù)定義某特定類型漏洞模式，通過模式匹配在執(zhí)行代碼上進(jìn)行漏洞挖掘[1]。挖掘輸入驗(yàn)證漏洞難點(diǎn)是難以給出漏洞通用模式。為更好檢測與程序邏輯相關(guān)漏洞，破解難點(diǎn)，筆者提出針對(duì)Android應(yīng)用輸入驗(yàn)證漏洞基于源代碼分析靜態(tài)挖掘方案。方案使用后向程序切片算法在控制流圖上提取事務(wù)切片和約束切片，通過頻繁模式挖掘獲得切片級(jí)隱式安全規(guī)范，驗(yàn)證規(guī)范并將違規(guī)現(xiàn)象報(bào)告為可疑漏洞，根據(jù)收集的路徑約束條件推斷輸入取值范圍，自動(dòng)化生成測試用例并在虛擬機(jī)上半自動(dòng)的驗(yàn)證漏洞報(bào)告。

1 輸入驗(yàn)證漏洞建模

傳統(tǒng)的漏洞挖掘方案都是經(jīng)過大量漏洞細(xì)節(jié)的人工分析，建立一個(gè)固定的漏洞模型，然后從代碼實(shí)現(xiàn)中查找符合該漏洞模型的代碼行為。由于無法對(duì)輸入驗(yàn)證漏洞用一個(gè)統(tǒng)一標(biāo)準(zhǔn)漏洞模型描述，因此“漏洞建模-模型檢測”的檢測模式不甚理想。由于Android功能設(shè)計(jì)中代碼存在大量重復(fù)片段，抽取重復(fù)片段的行為模式得到該程序應(yīng)該遵守的規(guī)范，不符合規(guī)范行為即為可疑漏洞[2]。為能提取出此類行為模式，需對(duì)輸入驗(yàn)證漏洞進(jìn)行形式化的建模。

定義事務(wù)。事務(wù)（Transaction）是包含一個(gè)核心語句及其所有數(shù)據(jù)依賴語句的語句集合。從定義可以看出，事務(wù)具有原子性，整個(gè)事務(wù)是一個(gè)不可分割的功能片段，所有語句一起完成某個(gè)特定的功能。一個(gè)事務(wù)通常用最后一條語句明確執(zhí)行某個(gè)功能，其他語句只是為該中心語句準(zhǔn)備所需的數(shù)據(jù)。

事務(wù)通過一個(gè)四元組T＜s,Ds,CS,Dv＞定義，其中s是整個(gè)事務(wù)的核心語句，Ds是事務(wù)所有依賴語句集合，CS是事務(wù)所有約束集合，Dv是事務(wù)所有依賴變量集合。

形式化定義如下，其中REF(si)是語句si所有依賴變量，DEF(si)是語句si中被賦值變量：

●s=o.fun(p1,p2,...,pn)

●Ds={s1,s2,...,sn},s1,s2,...,sn是順序執(zhí)行的語句，sn就是核心功能語句 s，則對(duì)于（i∈[2,n]）,存在 sj，j∈[1,i),DEF(sj)F(si)

●CS={cs1,cs2,...,csn},其中csi是事務(wù)T的約束（隨后定義）

●Dv={v|v∈{o,p1,p2,...,pn}ⅴv∈REF(si),si∈Ds}

定義約束。約束(Constraint)是一個(gè)事務(wù)可以被順利執(zhí)行所需滿足的一個(gè)路徑條件語句，代表著對(duì)這個(gè)事務(wù)執(zhí)行過程中變量或者環(huán)境的驗(yàn)證行為。一個(gè)事務(wù)通常會(huì)有多個(gè)約束，只有這些約束都得到滿足的時(shí)候，一個(gè)事務(wù)才能執(zhí)行完成。一個(gè)條件語句是一個(gè)事務(wù)約束的充要條件，是該約束在控制流圖上到達(dá)該事務(wù)路徑上的分支節(jié)點(diǎn)。

約束通過一個(gè)三元組T＜s,Ds,Dv＞定義，其中s是整個(gè)事務(wù)核心語句，Ds是事務(wù)所有依賴語句集合，Dv是事務(wù)所有依賴變量集合。形式化定義如下：

●s=o1.fun1(p1,p2,...,pn)relop o2.fun2(q1,q2,...,qn),relop是關(guān)系運(yùn)算符

●Ds={s1,s2,...,sn},s1,s2,...sn是順序執(zhí)行的語句，sn就是約束條件語句s,則對(duì)于si（i∈[2,n]）,存在sj,j∈[1,i），DEF（sj）REF(si)

●Dv={v|v∈{o,p1,p2,...,pn}ⅴ v∈REF(si),si∈ Ds}

定義輸入驗(yàn)證漏洞。輸入驗(yàn)證漏洞是一個(gè)事務(wù)缺少必要約束而導(dǎo)致。給定事務(wù)T＜s,Ds,CS,Dv＞和安全規(guī)范集合SR{s|sis necessary constraint}，T存在輸入驗(yàn)證漏洞。當(dāng)且僅當(dāng)：

從定義知，挖掘輸入驗(yàn)證漏洞關(guān)鍵在于如何提取安全規(guī)范集合SR，及判定一個(gè)約束對(duì)于一個(gè)事務(wù)是否是必要的。為能從源代碼中提取出事務(wù)和約束，使用后向程序切片技術(shù)(backward slicing)[3]細(xì)分程序邏輯，從某個(gè)程序點(diǎn)P出發(fā)，逆向遍歷重構(gòu)控制流圖并收集所有和程序點(diǎn)P存在數(shù)據(jù)依賴關(guān)系的語句和分支謂詞，進(jìn)而提取事務(wù)切片和約束切片。

2 系統(tǒng)設(shè)計(jì)

通過預(yù)處理、程序切片、漏洞檢測及漏洞驗(yàn)證設(shè)計(jì)基于隱式模式掘的漏洞挖掘流程。如圖1所示。

2.1 預(yù)處理

對(duì)Java源代碼進(jìn)行解析，獲取抽象語法樹 （Abstract Syntax Tree）和控制流圖、系統(tǒng)依賴圖(System Dependence Graph)[4]。為方便精確分析數(shù)據(jù)流，將復(fù)雜語句變成三地址模式靜態(tài)單賦值 (Static Single-Assignment)語句。每一條靜態(tài)單賦值語句只給一個(gè)變量賦值一次，根據(jù)manifest.xml文件重構(gòu)控制流圖。

圖1 基于隱式模式的漏洞挖掘流程

2.2 程序切片

利用后向切片技術(shù)，將某一安全敏感語句識(shí)別為切片中心語句，以它為起點(diǎn)，收集數(shù)據(jù)依賴語句作為事務(wù)切片。將路徑分支語句識(shí)別為切片中心語句，通過程序切片技術(shù)獲得約束切片。

2.3 漏洞檢測

用事務(wù)切片和切片代表程序邏輯的抽象，在切片級(jí)別進(jìn)行漏洞檢測。首先，依據(jù)中心語句不同將事務(wù)切片進(jìn)行分類；提取同一類事務(wù)中出現(xiàn)頻繁的約束切片為隱式安全規(guī)范，并應(yīng)用到該類事務(wù)中，不滿足規(guī)范切片識(shí)別為可疑安全漏洞。

2.4 漏洞驗(yàn)證

通過半自動(dòng)漏洞驗(yàn)證模塊對(duì)原始漏洞報(bào)告進(jìn)行驗(yàn)證。在一臺(tái)Android虛擬機(jī)上驗(yàn)證簡單輸入漏洞；對(duì)于復(fù)雜漏洞，輸入求解過程結(jié)果不理想，但一定程度上能輔助人工分析并生成最終報(bào)告，報(bào)告中包含受影響的切片和修復(fù)方案。

3 系統(tǒng)實(shí)現(xiàn)

在系統(tǒng)設(shè)計(jì)基礎(chǔ)上實(shí)現(xiàn)基于隱式模式的漏洞挖掘各個(gè)模塊細(xì)節(jié)。

3．1 預(yù)處理

在實(shí)現(xiàn)系統(tǒng)設(shè)計(jì)中預(yù)處理功能外，需增加針對(duì)異常拋出Assert語句和Service Hook API的處理，以方便收集更多種類約束。

Assert語句。Java語言中Assert語句是斷言式語句，幫助開發(fā)者動(dòng)態(tài)驗(yàn)證特定程序點(diǎn)是否滿足預(yù)設(shè)條件[5]。若不滿足，Assert語句拋出AssertionError異常，Catch語句捕獲異常，否則控制流直接結(jié)束函數(shù)或程序。為處理該情況，將Assert語句條件表達(dá)式轉(zhuǎn)變?yōu)镮F語句，使其成為后續(xù)所有語句的隱式約束。

Service Hook API。Service HookAPI用于動(dòng)態(tài)細(xì)粒度驗(yàn)證訪問者權(quán)限，用于保護(hù)某個(gè)Service組件方法。在調(diào)用時(shí)檢查調(diào)用者權(quán)限，權(quán)限不夠則拋出異常。Service Hook作為靜態(tài)權(quán)限機(jī)制補(bǔ)充，需將其識(shí)別為約束，處理方法同Assert語句。

3．2 程序切片

程序切片采用的提取算法，能同時(shí)提取事務(wù)切片和約束切片。算法思路是從函數(shù)最后一條語句(通常是return語句)開始，逆向遍歷控制流圖，將所有安全敏感函數(shù)調(diào)用語句識(shí)別為切片中心語句，利用后向切片算法提取事務(wù)切片。從安全敏感函數(shù)調(diào)用語句開始，逆向遍歷控制流圖，收集所有數(shù)據(jù)依賴，直到控制流圖入口點(diǎn)止。獲得包含一個(gè)切片中心語句和所有數(shù)據(jù)依賴語句的完整事務(wù)切片。

帶著這樣的問題，我梳理了自己30年的語文教學(xué)，研究了于漪、錢夢龍等一大批語文教學(xué)名家的教育實(shí)踐，尤其是他們的課堂教學(xué)，驚喜地發(fā)現(xiàn)：新課改從理念到實(shí)踐，不是憑空而來的，也不像有些人所理解的是從西方引進(jìn)的（其他學(xué)科或許可以引進(jìn)，但母語教學(xué)是不能引進(jìn)的），而是在繼承中發(fā)展的。新課程的很多理念在這一批教育名家的課堂上早就有了充分的體現(xiàn)。

切片示例：圖2是從函數(shù)stk.BootCompletedReceiver.onReceive()中提取事務(wù)切片和所有相關(guān)約束切片。第4條語句是敏感API context.startService(),該API啟動(dòng)組件間通信service組件。本示例列出該事務(wù)切片包含的1條約束，該約束檢查action變量是否等于某個(gè)確定值，而其數(shù)據(jù)依賴關(guān)系最后都指向輸入函數(shù)參數(shù)（即 Intent）。

圖2 事務(wù)切片和約束切片示例

3．3 漏洞檢測

從程序切片中提取隱式安全規(guī)范是破解預(yù)先不能提供統(tǒng)一漏洞模式和安全規(guī)范的有效算法。通過事務(wù)分類、提取隱式安全規(guī)范和驗(yàn)證安全規(guī)范等流程將提取事務(wù)切片按切片中心語句是否相等劃分為不同類別，頻繁挖掘各事務(wù)類別所有約束切片，在滿足安全規(guī)范的事務(wù)類別中檢測可疑違規(guī)行為。如果某事務(wù)切片缺少某相關(guān)聯(lián)安全規(guī)范，認(rèn)為該事務(wù)切片存在可疑漏洞。

3.3.1 事務(wù)分類

相似事務(wù)具有相似約束，先利用切片中心語句的相等性對(duì)事務(wù)切片進(jìn)行分類。給定兩個(gè)事務(wù)切片中心語句o_1.fun_1(p_1,p_2,…,p_n)和o_2.fun_2(q_1,q_2,…,q_n)，兩個(gè)中心語句相等條件是o1和o2實(shí)例化自同一個(gè)類或繼承自同一個(gè)父類的兩個(gè)子類，且兩個(gè)函數(shù)名相等，參數(shù)也相同。

形式化定義如下：給定o1的類O1,o2的類O2，符號(hào)“＜”代表類的繼承關(guān)系，px的類Px和qx的類Qx，那么

這里將Android組件間通信API族(startActivity(),startService(),sendBroadcast()等)統(tǒng)一識(shí)別為相等切片中心語句[6]。

3.3.2 提取隱式安全規(guī)范

抽取該事務(wù)類別所有約束切片，匯總到約束切片集合中，提取多于N次出現(xiàn)的約束切片作為安全規(guī)范。采用約束切片中心語句相等性代表約束切片相等性,給定兩個(gè)約束切片中心語句o1.fun1(...)relop o2.fun2(...)和 o1’.xfun1’(...)relop’o2’.fun2’(...)其中 relop 是關(guān)系運(yùn)算符（＜,＜=,=,＜＞,＞,＞=等），o.fun(...)為 Null，或者 relop和o2.fun2(...)均為空，這樣所有約束切片語句可化成如上形式。

注意，為盡量收集更多約束信息，約束切片出現(xiàn)頻數(shù)N的閾值設(shè)為1，會(huì)導(dǎo)致一定程度提高誤報(bào)率，若提高閾值會(huì)降低誤報(bào)率，但會(huì)升高漏報(bào)率。綜合考慮選擇閾值為1。

利用已提取安全規(guī)范驗(yàn)證事務(wù)分類中規(guī)范并檢測可疑違規(guī)行為[7]。如果一個(gè)事務(wù)和一個(gè)安全規(guī)范存在相關(guān)性，該事務(wù)約束切片不包含該安全規(guī)范，那么該事務(wù)由于缺失該安全規(guī)范存在安全漏洞。檢測事務(wù)和安全規(guī)范相關(guān)性的判定標(biāo)準(zhǔn)是：變量數(shù)據(jù)類型是判定兩個(gè)依賴變量集相等性的根據(jù)，當(dāng)一個(gè)事務(wù)依賴變量集（Dependence Variables）包含提取安全規(guī)范的依賴變量集時(shí)，認(rèn)為該事務(wù)和安全規(guī)范存在相關(guān)性。如一個(gè)事務(wù)依賴變量集為 {Intent,Message,SmsMessage,Context}，安全規(guī)范依賴變量集為{Context,Intent,String,int}，去掉基礎(chǔ)類型后，由于{Context,Intent}?{Intent,Message,SmsMessage,Context}，那么就認(rèn)為該安全規(guī)范與該事務(wù)是相關(guān)的。

3.4 漏洞驗(yàn)證

由于輸入驗(yàn)證漏洞敏感API不一定是系統(tǒng)API，對(duì)它調(diào)用不經(jīng)過ActivityManagerService仲裁，所以不能完備監(jiān)控此類調(diào)用。因此，設(shè)計(jì)一個(gè)自動(dòng)化漏洞驗(yàn)證模塊，選擇使用靜態(tài)插樁方法監(jiān)控API調(diào)用。如圖3所示，使用Soot修改目標(biāo)APK二進(jìn)制代碼，插入一條新語句在被關(guān)注API調(diào)用語句前，記錄API調(diào)用信息和上下文信息到系統(tǒng)日志中，重新打包APK并安裝到Android虛擬機(jī)或物理機(jī)中。

同時(shí)使用簡單約束求解器推斷輸入，利用代碼發(fā)送到目標(biāo)Android機(jī)器中，再使用logcat監(jiān)控系統(tǒng)日志，發(fā)現(xiàn)API調(diào)用信息或者app崩潰信息及時(shí)記錄，并輸出驗(yàn)證報(bào)告。如果監(jiān)控到預(yù)期行為，將該可疑漏洞標(biāo)記為“Confirmed Vul”，否則標(biāo)記為“False Alarm”。如果不存在可執(zhí)行文件（.apk）或漏洞輸入條件無法求得，那么將其標(biāo)記為“Unconfirmed Alarm”。

圖3 基于靜態(tài)插樁的漏洞驗(yàn)證

4 實(shí)驗(yàn)結(jié)果及分析

選取packages/apps和packages/providers中應(yīng)用源碼在不同版本Android原生系統(tǒng)進(jìn)行測試，測試集詳情見表1。

表1 測試集匯總

在App上應(yīng)用算法得到相應(yīng)可疑漏洞報(bào)告，通過人工審核源代碼并編寫利用代碼的方式來驗(yàn)證這些漏洞。驗(yàn)證結(jié)果見表2。其中列“Apps”是存在漏洞app包名，列“Vulnerable Component”是存在該漏洞組件名，×表示該版本不存在App（NFC功能在Android2.3之后才引入），表示無漏洞。

實(shí)驗(yàn)表明，設(shè)計(jì)工具共檢測到36個(gè)未公開輸入驗(yàn)證漏洞，均為拒絕服務(wù)漏洞，這些漏洞通過合適場景能造成嚴(yán)重破壞；Android版本迭代更新若干年，拒絕服務(wù)漏洞數(shù)量細(xì)微變化造成的損失并沒有引起程序員足夠重視。

表2 檢測到的輸入驗(yàn)證漏洞

5 結(jié)語

為檢測和程序邏輯相關(guān)、難以提取統(tǒng)一模式輸入驗(yàn)證漏洞，本文提出基于隱式模式挖掘，用于發(fā)現(xiàn)源代碼中隱含安全規(guī)范并檢測漏洞。該技術(shù)應(yīng)用后向程序切片技術(shù)提取程序邏輯，抽取獨(dú)立功能代碼片段為一個(gè)事務(wù)切片，抽取一個(gè)路徑約束條件和相關(guān)語句代碼片段為一個(gè)約束切片，在切片級(jí)別上進(jìn)行事務(wù)切片分類，在類別內(nèi)采用頻繁模式挖掘，提取隱式安全規(guī)范檢測漏洞。在Android2.2、4.0.3、4.4.2和5.0等版本上實(shí)現(xiàn)一個(gè)原型系統(tǒng)，檢測出36個(gè)拒絕服務(wù)漏洞，充分驗(yàn)證該方案不僅能從源代碼中有效提取隱式安全規(guī)范并挖掘漏洞，同時(shí)通過自動(dòng)化樣本生成和自動(dòng)化驗(yàn)證顯著降低誤報(bào)率。