基于Clang編譯前端的Android源代碼靜態(tài)分析技術(shù)①

曹原野 ,丁麗萍

1(中國(guó)科學(xué)院 軟件研究所 基礎(chǔ)軟件實(shí)驗(yàn)室,北京 100190)2(中國(guó)科學(xué)院大學(xué),北京 100049)

基于Clang編譯前端的Android源代碼靜態(tài)分析技術(shù)①

曹原野1,2,丁麗萍1

1(中國(guó)科學(xué)院 軟件研究所 基礎(chǔ)軟件實(shí)驗(yàn)室,北京 100190)2(中國(guó)科學(xué)院大學(xué),北京 100049)

Android手機(jī)在全球占有很大的市場(chǎng)份額,基于Android衍生的第三方系統(tǒng)也為數(shù)不少.針對(duì)Android系統(tǒng)重大安全問題頻發(fā)的現(xiàn)狀,提出一種使用Clang編譯前端對(duì)Android源碼進(jìn)行靜態(tài)分析的方法.該方法從已公布的CVE漏洞中提取規(guī)則和模型,通過改進(jìn)的Clang編譯前端,對(duì)Android源碼進(jìn)行靜態(tài)分析,從而檢測(cè)出有潛在安全風(fēng)險(xiǎn)的代碼片段.在對(duì)Android源碼進(jìn)行污點(diǎn)分析時(shí),調(diào)用新加入的stp約束求解器,通過符號(hào)執(zhí)行,對(duì)敏感數(shù)據(jù)進(jìn)行污點(diǎn)標(biāo)記,并對(duì)敏感函數(shù)、敏感操作、敏感規(guī)則進(jìn)行污點(diǎn)分析,如果存在潛在的安全隱患,則進(jìn)行報(bào)告.經(jīng)過實(shí)驗(yàn)分析,該方法可以找出Android源代碼中存在的同類型有安全風(fēng)險(xiǎn)的代碼片段,可以檢出libstagefright模塊5個(gè)高危CVE漏洞.

Clang 編譯器; 安卓; 靜態(tài)分析; 污點(diǎn)分析; 符號(hào)執(zhí)行

1 引言 111

Android系統(tǒng)因其開源性和開放性,在智能手機(jī)市場(chǎng)占有很大的市場(chǎng)份額.近些年來,Android系統(tǒng)不斷發(fā)展,在智能家電、物聯(lián)網(wǎng)等領(lǐng)域迅速攻占市場(chǎng),與人們的日常生活越來越緊密相關(guān).然而,Android系統(tǒng)的安全問題日益突出,不斷爆出影響極大的安全漏洞,不僅影響了用戶的使用體驗(yàn),更嚴(yán)重威脅到了用戶的隱私,例如:具備麥克風(fēng)或攝像頭的Android智能電視被遠(yuǎn)程控制,將會(huì)造成非?？膳碌碾[私泄露.因此,Android硬件廠商在硬件發(fā)布之前,非常有必要對(duì)定制的Android系統(tǒng)進(jìn)行安全審計(jì),以盡可能地減少潛在的安全隱患.對(duì)定制的Android源代碼進(jìn)行安全審計(jì)在保護(hù)用戶的隱私、減少企業(yè)的開發(fā)成本方面有重要意義.

在研究Android源代碼的CVE(Common vulnerabilities and exposures)漏洞補(bǔ)丁的過程中,發(fā)現(xiàn)部分漏洞存在特定的規(guī)律和模式.本文對(duì)這些規(guī)律和模式進(jìn)行了總結(jié)分析,提出了一種基于改進(jìn)的Clang編譯前端進(jìn)行安全分析的靜態(tài)檢測(cè)方法,該方法通過Clang編譯前端對(duì)指定的Android模塊進(jìn)行符號(hào)執(zhí)行[1,2],通過污點(diǎn)傳播對(duì)敏感數(shù)據(jù)進(jìn)行標(biāo)記,通過對(duì)特定的函數(shù)[3,4]、條件分支、語法結(jié)構(gòu)進(jìn)行污點(diǎn)分析,找到有潛在安全風(fēng)險(xiǎn)的代碼片段,并給出相應(yīng)的檢查報(bào)告.企業(yè)在對(duì)Android系統(tǒng)進(jìn)行定制修改之后,如果能夠在系統(tǒng)發(fā)布之前,對(duì)Android定制系統(tǒng)的源代碼進(jìn)行安全審計(jì),則可以有效降低定制系統(tǒng)的安全風(fēng)險(xiǎn)所帶來的損失[5],同時(shí)因?yàn)閷徲?jì)的自動(dòng)化,也可以大幅降低人力成本.

2 相關(guān)研究

代碼審計(jì)的最終目標(biāo)是挖掘軟件中潛在的有安全風(fēng)險(xiǎn)的漏洞代碼.目前,針對(duì)Android系統(tǒng)的漏洞挖掘已經(jīng)有很多成熟的方法.例如:人工審查、模糊測(cè)試、動(dòng)態(tài)分析、靜態(tài)分析等方法.

人工審查就是通過人工閱讀代碼的方式對(duì)源代碼進(jìn)行逐行逐行地分析,判斷是否有安全問題.這要求審查人員有相當(dāng)深厚的審查經(jīng)驗(yàn),而且很費(fèi)時(shí)間,適用于簡(jiǎn)短但是易錯(cuò)的代碼,如驅(qū)動(dòng)代碼.

模糊測(cè)試(Fuzz)是指通過給目標(biāo)接口輸入大量的隨機(jī)數(shù)據(jù),來測(cè)試接口是否能夠正常處理這些畸形數(shù)據(jù)的測(cè)試方法.如果接口或系統(tǒng)出現(xiàn)了異常,則認(rèn)為接口極有可能存在缺陷.模糊測(cè)試的優(yōu)點(diǎn)是簡(jiǎn)單有效,但是相當(dāng)耗費(fèi)時(shí)間,因?yàn)槭请S機(jī)生成的數(shù)據(jù),所以具有一定的概率性.而且測(cè)試速率要受制于目標(biāo)接口的響應(yīng)速率.對(duì)應(yīng)的工具有Peach等.Peach是一個(gè)遵守MIT開源許可證的模糊測(cè)試框架,用戶通過編寫Peach Pit配置文件,可以定義Fuzz過程的配置和原始數(shù)據(jù)結(jié)構(gòu)的定義.通過定義原始數(shù)據(jù)結(jié)構(gòu)生成結(jié)構(gòu)化的部分隨機(jī)數(shù)據(jù),來實(shí)現(xiàn)精確的模糊測(cè)試.

動(dòng)態(tài)分析是指對(duì)二進(jìn)制程序進(jìn)行插樁,來達(dá)到運(yùn)行時(shí)對(duì)程序的控制和監(jiān)控.動(dòng)態(tài)分析的優(yōu)點(diǎn)是準(zhǔn)確率高,覆蓋面大,但是缺點(diǎn)是依賴于運(yùn)行平臺(tái),有路徑爆炸的風(fēng)險(xiǎn),并且在編譯過程中損失了一些代碼的細(xì)節(jié)信息.對(duì)應(yīng)的工具有 Pin、KLEE、Android_S2E[20]等.Pin是Intel公司提供的二進(jìn)制插樁工具[6],它允許在可執(zhí)行程序的任何地方插入任意代碼[7].KLEE是一款源代碼動(dòng)態(tài)符號(hào)執(zhí)行工具.KLEE需要修改源代碼,通過對(duì)源代碼內(nèi)特定的輸入數(shù)據(jù)進(jìn)行標(biāo)記,插入自己的符號(hào)執(zhí)行代碼,然后編譯執(zhí)行并收集變量信息.Android_S2E是一款全系統(tǒng)符號(hào)執(zhí)行工具,它預(yù)裝QEMU模擬器和KLEE在虛擬機(jī)上運(yùn)行Android,并執(zhí)行符號(hào)執(zhí)行,可以遍歷Android系統(tǒng)上小型C語言程序的所有路徑.

靜態(tài)分析是指在不運(yùn)行代碼的情況下,通過多種方式對(duì)源代碼進(jìn)行分析之后,得出源代碼是否存在問題的結(jié)論.分析方法涵蓋簡(jiǎn)單的正則、詞法分析、語法分析、上下文路徑敏感分析等.對(duì)應(yīng)的工具有Coverity、Clang等.Coverity是一個(gè)先進(jìn)的、可配置的用于檢測(cè)軟件缺陷和安全隱患的靜態(tài)代碼分析解決方案,它能自動(dòng)化地檢測(cè)和解決C、C++、Java、C#源代碼中多種類型的缺陷,Coverity對(duì)Android系統(tǒng)有針對(duì)性優(yōu)化,但是Coverity是收費(fèi)且閉源的.Clang是LLVM開源編譯套件的一個(gè)編譯前端,負(fù)責(zé)將C、C++、Object-C源代碼翻譯為中間代碼[8,9],而且Clang自身具備靜態(tài)分析的能力,可以在不運(yùn)行代碼的情況下對(duì)代碼進(jìn)行編譯分析.

現(xiàn)有Android系統(tǒng)安全問題的文獻(xiàn)研究多數(shù)集中在Android應(yīng)用層上的研究.對(duì)于Android系統(tǒng)自身底層代碼的安全研究的文獻(xiàn)研究其實(shí)不常見[10,11].移動(dòng)安全會(huì)議上提到的工業(yè)界常用的方法多集中于模糊測(cè)試的方法.使用模糊測(cè)試的方法雖然具有一定的隨機(jī)性,但是簡(jiǎn)單便捷,并且短期內(nèi)容易看到成效.但是,安全研究員如果想要建立一種長(zhǎng)效的安全機(jī)制,這種機(jī)制是穩(wěn)定的,而且可以逐步完善、逐步歸納吸收已有的安全風(fēng)險(xiǎn)的話,使用靜態(tài)分析是一種非常合適的方案.

靜態(tài)分析沒有模糊測(cè)試的隨機(jī)性,分析結(jié)果比較穩(wěn)定.并且,通過對(duì)現(xiàn)有的安全風(fēng)險(xiǎn)進(jìn)行歸納吸收,可以不斷完善靜態(tài)分析工具,那么靜態(tài)分析工具就能夠在檢測(cè)能力上得到持續(xù)加強(qiáng).而一款能夠持續(xù)加強(qiáng)的靜態(tài)分析工具必須是開源的,所以本文主要調(diào)研了Clang編譯前端對(duì)Android源代碼進(jìn)行靜態(tài)分析的難點(diǎn).

本文經(jīng)過調(diào)研,使用Clang成功對(duì)Android源代碼進(jìn)行了分析,并主要克服了 3個(gè)方面的困難.1)新版的Clang 3.8無法直接對(duì)Android源代碼進(jìn)行分析,需要做兼容處理.2)Clang自帶的約束求解器的求解能力過弱,不適合應(yīng)用在Android源代碼這種復(fù)雜項(xiàng)目上.3)Clang自帶的檢測(cè)規(guī)則是通用檢測(cè)規(guī)則,沒有針對(duì)Android源代碼的檢測(cè)規(guī)則,導(dǎo)致檢測(cè)能力過弱.

本文克服了上述3個(gè)困難,最終實(shí)現(xiàn)了目標(biāo):實(shí)現(xiàn)一種工業(yè)界可用的,基于改進(jìn)的Clang編譯前端的,用于Android系統(tǒng)源代碼的靜態(tài)分析方法.

3 基于Clang編譯前端的靜態(tài)分析原理

Clang作為L(zhǎng)LVM編譯套件的編譯前端,自帶一個(gè)靜態(tài)代碼分析工具,可以編譯分析C、C++、Object-C源代碼,此靜態(tài)分析工具屬于Clang的一部分因而完全開源.

Clang在對(duì)源代碼進(jìn)行編譯的時(shí)候,會(huì)通過靜態(tài)分析,對(duì)代碼風(fēng)格、語法錯(cuò)誤和潛在的風(fēng)險(xiǎn)進(jìn)行warning警告.Clang靜態(tài)分析器通過自定義代碼可以實(shí)現(xiàn)更復(fù)雜的檢測(cè)機(jī)制來進(jìn)行靜態(tài)分析.Clang的靜態(tài)分析器首先通過程序代碼,生成AST(語法樹),然后根據(jù)AST生成 CFG(控制流圖),通過符號(hào)執(zhí)行生成擴(kuò)展圖(ExplodedGraph),具體控制流程如圖1[12]所示.

圖1 Clang 的靜態(tài)分析過程

通過自定義Checker(Clang中的檢查器,用來檢測(cè)自定義缺陷),可以實(shí)現(xiàn)對(duì)AST和ExplodedGraph的分析和控制.Checker不僅僅只能是被動(dòng)的調(diào)用,Checker也能主動(dòng)地修改ExplodedGraph.如果Checker認(rèn)為存在特定的缺陷,就可以調(diào)用BugReport來報(bào)告存在的缺陷,方便測(cè)試人員可視化地觀察檢測(cè)信息.

Clang的AST樹近似于常規(guī)的編程語法結(jié)構(gòu).通過“clang-Xclang-ast-dump example.cpp”可以對(duì)源代碼生成的AST進(jìn)行觀察.AST語法樹主要由兩類結(jié)點(diǎn)(Stmt與Decl)和派生自他們的子結(jié)點(diǎn)構(gòu)成.Stmt是指statement語句,Decl是指 declarations聲明.

Clang的CFG控制流圖由若干個(gè)CFGBlock塊組成,每個(gè)CFGBlock均包含有EXIT塊和ENTRY塊.并且每個(gè)CFGBlock塊由一組CFGElement組成,其中的CFGElement代表AST樹中的一個(gè)結(jié)點(diǎn).

Clang的ExplodedGraph圖是在通過符號(hào)執(zhí)行遍歷CFG圖的時(shí)候產(chǎn)生的.ExplodedGraph中的每個(gè)結(jié)點(diǎn),都包含了 ProgramPoint點(diǎn)和 State 信息.Program-Point點(diǎn),用來定義源代碼運(yùn)行到該點(diǎn)時(shí)所有變量的值.State信息用來表示源代碼在符號(hào)執(zhí)行過程中的狀態(tài)信息,包括:表達(dá)式到值的映射關(guān)系、各種變量到值的映射關(guān)系、路徑條件約束等信息.

通過Clang的源碼,可以發(fā)現(xiàn),如果將Clang的靜態(tài)分析直接應(yīng)用到Android系統(tǒng)源碼之上,基本沒有效果.一個(gè)原因是Clang自帶的range約束求解器的求解能力過于薄弱,只能處理簡(jiǎn)單約束.另一個(gè)原因是Clang作為一個(gè)通用編譯前端,更注重的是通用性,所以特定問題的檢測(cè)能力不強(qiáng).需要對(duì)Clang的符號(hào)執(zhí)行能力和檢測(cè)能力進(jìn)行增強(qiáng).所以,以下小節(jié)將逐個(gè)描述對(duì)Clang進(jìn)行加強(qiáng)的實(shí)現(xiàn)原理.

3.1 改進(jìn)Clang靜態(tài)分析Android源碼的兼容性

Android源碼內(nèi),含有LLVM的預(yù)編譯工具鏈,但是直到最新的Android7.1的源代碼,LLVM預(yù)編譯工具鏈中Clang的版本仍舊是3.3版本.本文需要定制較新的Clang3.8版本進(jìn)行靜態(tài)分析.所以需要了解Clang靜態(tài)分析指令和Android源代碼的編譯腳本工作原理.

Clang靜態(tài)分析由兩個(gè)指令構(gòu)成,分別是“scanbuild”和“scan-view”命令.“scan-build”命令后面緊接著正常的編譯命令,例如“scan-build g++ example.cpp”或者“scan-build make-j4”這種編譯命令.其中“scan-build”命令會(huì)對(duì)后面的編譯命令進(jìn)行分析,替換其中的編譯器為Clang本身,則Clang可以順利地進(jìn)行靜態(tài)分析.“scan-build”在分析完畢之后,會(huì)留下一個(gè)特殊的目錄,使用“scan-view”打開這個(gè)目錄,則可以顯示分析報(bào)表.

Android源代碼的編譯腳本主要集中在源代碼根目錄的build/envsetup.sh文件里.其中主要有4個(gè)編譯命令,分別是 mmm、mm、m、make 命令.mmm 命令主要用于編譯指定路徑下的模塊,mm命令用于編譯當(dāng)前路徑下的模塊,m命令編譯當(dāng)前目錄下的所有模塊,make命令則是編譯整個(gè)Android系統(tǒng).為了靜態(tài)分析的需要,主要進(jìn)行單個(gè)模塊的分析,所以選用mmm命令.通過更換mmm命令后的路徑,可以實(shí)現(xiàn)不同模塊的靜態(tài)分析.“mmm path-B”其中的“-B”參數(shù)則是無論源碼修改與否都強(qiáng)制編譯path目錄下的所有源碼.

直接使用“scan-build mmm path-B”則會(huì)直接報(bào)錯(cuò).通過研究envsetup.sh的代碼,發(fā)現(xiàn)在getdriver函數(shù)聲明了靜態(tài)分析的使用規(guī)則和“scan-build”的二進(jìn)制路徑,將getdriver函數(shù)的“scan-build”路徑改為改進(jìn)的Clang源代碼生成的“scan-build”路徑.同時(shí)執(zhí)行“WITH_STATIC_ANALYZER=1 mmm path-B”則可成功啟動(dòng)改進(jìn)Clang的靜態(tài)分析.但是,分析途中一定會(huì)出錯(cuò),因?yàn)楦甙姹镜腃lang已經(jīng)不支持一些舊命令參數(shù),所以需要對(duì)“scan-build”編譯腳本調(diào)用的其他編譯腳本進(jìn)行兼容修改.經(jīng)過修改的的編譯腳本可以正確對(duì)某個(gè)模塊進(jìn)行靜態(tài)分析.

3.2 增強(qiáng)Clang的符號(hào)執(zhí)行能力

SMT(Satisfiability modulo theories)可以用來解決邏輯公式的決策問題[13],可以用來處理布爾運(yùn)算、量詞、算術(shù)運(yùn)算、比較運(yùn)算、位運(yùn)算等約束性求解問題.SMT模型有一些具體的約束求解器實(shí)現(xiàn),例如:z3約束求解器、stp約束求解器等.這些求解器具備強(qiáng)大的求解能力,可以處理編程語言中常見的復(fù)雜條件判斷、位運(yùn)算、數(shù)組操作等.

符號(hào)執(zhí)行是CFG生成ExplodedGraph時(shí)使用的.Clang靜態(tài)分析程序讀取CFG,當(dāng)遇到條件分支時(shí),會(huì)根據(jù)不同的條件分支,依次執(zhí)行不同的條件分支.在執(zhí)行不同的條件分支之前,符號(hào)執(zhí)行會(huì)把進(jìn)去當(dāng)前分支所需要的條件放入約束求解器查詢,如果當(dāng)前條件滿足約束求解器,則執(zhí)行分支并把分支條件放入約束求解器,否則不執(zhí)行當(dāng)前分支.

Clang具備符號(hào)執(zhí)行的能力,但是其自帶的range約束求解器能力不強(qiáng),只支持簡(jiǎn)單約束條件,遇到多元約束條件不能處理則忽略,這大大削弱了符號(hào)執(zhí)行的準(zhǔn)確性.在實(shí)際的復(fù)雜代碼中,這個(gè)自帶的約束求解器在精度方面經(jīng)常不能滿足預(yù)想的要求.

但是Clang本身支持約束求解器的擴(kuò)展,可以通過仿照range約束求解器的編寫方式,修改Clang配置文件,增加新的約束求解器,達(dá)到增強(qiáng)約束求解器的目的.

本文通過修改Clang源碼,加入了stp約束求解器,使Clang可以處理復(fù)雜的多元約束求解.通過增強(qiáng)Clang符號(hào)執(zhí)行的約束求解能力,提高其檢測(cè)精度.

3.3 增強(qiáng)Clang的靜態(tài)檢測(cè)能力

作為一款通用編譯前端,Clang所面對(duì)的是通用場(chǎng)景的代碼.其靜態(tài)分析里的檢測(cè)規(guī)則面向的是常見的缺陷問題.所以,Clang對(duì)于特殊模式的問題無法進(jìn)行正確檢測(cè)而得出結(jié)果.于是,在使用Clang對(duì)Android的源碼進(jìn)行分析之前,需要預(yù)先增強(qiáng)Clang的靜態(tài)檢測(cè)能力.

對(duì)于Android系統(tǒng),如果Clang想要檢測(cè)出安全風(fēng)險(xiǎn),就需要預(yù)先知道可能的攻擊面.Android系統(tǒng)因?yàn)樨S富的交互功能,其本身具有很多潛在的攻擊面.攻擊面可以分為 4 類.1)遠(yuǎn)程攻擊面:主要包含了網(wǎng)絡(luò)協(xié)議棧、對(duì)外暴露的網(wǎng)絡(luò)服務(wù)、短信、彩信、基礎(chǔ)軟件(瀏覽器接口、多媒體和文檔處理、電子郵件)等.2)物理相鄰的攻擊面:無線、藍(lán)牙、NFC 等.3)本地攻擊面:文件系統(tǒng)、系統(tǒng)調(diào)用等.4)物理連接攻擊面:USB連接等.

可被用戶控制的數(shù)據(jù)從這些攻擊面,流入到系統(tǒng)的控制流中,如果處理不當(dāng),則可能會(huì)引入安全風(fēng)險(xiǎn).所以,靜態(tài)分析的主要目標(biāo),就是需要頻繁從攻擊面獲取數(shù)據(jù)的模塊,例如:libstagefright模塊.為此,需要設(shè)定一段污點(diǎn)傳播程序,對(duì)Android源碼中有可能從攻擊面引入的危險(xiǎn)數(shù)據(jù)加上污點(diǎn)標(biāo)記.并對(duì)污染的數(shù)據(jù)進(jìn)行污點(diǎn)傳播,即圖2的“敏感函數(shù)污點(diǎn)標(biāo)記”.敏感函數(shù)例如:內(nèi)存操作函數(shù)、網(wǎng)絡(luò)操作函數(shù)、緩沖區(qū)管理函數(shù)、文件管理函數(shù)等.

圖2 增強(qiáng)的靜態(tài)檢測(cè)邏輯

在Android源代碼里,充滿了大量的宏定義和復(fù)雜的工具類,給開發(fā)人員帶來了巨大的便利,但是也給開發(fā)人員帶來了困擾:有時(shí)候會(huì)不記得當(dāng)前的變量到底是什么類型,有時(shí)候會(huì)忘記一些必須的操作.以下總結(jié)一些在Android源代碼漏洞中常見的錯(cuò)誤模式.

(1)敏感函數(shù)的參數(shù)錯(cuò)誤

memcpy(dest,src,len);

在復(fù)雜邏輯中,開發(fā)人員可能會(huì)忽略對(duì)len的正確約束,導(dǎo)致len可以賦值為一個(gè)超大的整數(shù)值.

(2)隱式轉(zhuǎn)換

memcpy(dest,src,len);

在開發(fā)中,開發(fā)人員混淆了len的類型,直接將有符號(hào)數(shù)直接傳入?yún)?shù),同時(shí)沒有限制len必須大于等于0.

long long a = int_b + int_c + (long long)d;

在開發(fā)中,遇到一個(gè)復(fù)雜計(jì)算式,而且數(shù)據(jù)類型不一致時(shí),開發(fā)人員意識(shí)到需要進(jìn)行強(qiáng)制類型轉(zhuǎn)換.但是強(qiáng)制類型轉(zhuǎn)換過晚,int_b和int_c已經(jīng)發(fā)生了溢出并進(jìn)行了隱式轉(zhuǎn)換之后,才與d變量進(jìn)行相加.

(3)分支條件

if(int_e+100

在開發(fā)中,開發(fā)人員忘記int_e的范圍沒有進(jìn)行約束,有可能發(fā)生溢出.

if(int_j < uint_k)

在開發(fā)中,開發(fā)人員忘記int_j的類型,且沒有約束int_j必須大于等于0.

為了對(duì)上述3種錯(cuò)誤模式進(jìn)行追蹤檢查,要預(yù)先設(shè)定鉤子函數(shù)進(jìn)行捕獲,當(dāng)鉤子函數(shù)捕捉到其中之一的模式正在發(fā)生,且包含有污點(diǎn)數(shù)據(jù)的時(shí)候,啟動(dòng)進(jìn)一步分析.例如:內(nèi)存分配函數(shù)、變量隱式轉(zhuǎn)換、條件判斷表達(dá)式這三種情況.這三種情況依次對(duì)應(yīng)圖2中的“敏感函數(shù)污點(diǎn)分析”,“污點(diǎn)數(shù)據(jù)類型轉(zhuǎn)換”,“分支條件判斷污點(diǎn)”.啟動(dòng)進(jìn)一步分析之后,對(duì)應(yīng)到圖2中的“溢出判斷”和“規(guī)則判斷”.

“溢出判斷”是指通過獲取污點(diǎn)變量的取值范圍[14,15],判斷是否存在于合法的區(qū)間.首先,通過Clang獲取污點(diǎn)變量的類型,根據(jù)變量類型生成對(duì)應(yīng)的最大值和最小值.通過stp約束求解器的查詢功能,查詢污點(diǎn)變量是否能夠取到最大值的同時(shí)再取到最小值,如果可以同時(shí)取到,則認(rèn)為存在風(fēng)險(xiǎn).

“規(guī)則判斷”是指通過設(shè)定若干組語法樹規(guī)則,對(duì)含有污點(diǎn)數(shù)據(jù)的語法樹進(jìn)行匹配判斷.例如:當(dāng)發(fā)現(xiàn)污點(diǎn)數(shù)據(jù)在二元算式之后發(fā)生了類型提升,而且是隱式類型提升的時(shí)候,說明在編程語法上存在安全風(fēng)險(xiǎn),此時(shí)可提示有潛在的安全風(fēng)險(xiǎn).

4 Android 源碼靜態(tài)分析的實(shí)現(xiàn)

4.1 對(duì)Android源代碼的修改

建立Android源代碼的本地mirror,從mirror拉取branch為android-5.1.1_r14(為了進(jìn)行對(duì)比實(shí)驗(yàn),需要拉取若干個(gè)branch)的分支,安裝好編譯工具,配置Android5.1.1的編譯環(huán)境和二進(jìn)制輸出目錄,進(jìn)入Android代碼目錄,執(zhí)行代碼1的指令.

代碼1.編譯所有Android源代碼$ source build/envsetup.sh$ lunch aosp_arm-eng$ make -j4

在靜態(tài)分析之前,必須先整體編譯一次Android,因?yàn)橐粋€(gè)模塊在編譯的時(shí)候經(jīng)常會(huì)依賴其他模塊,如果在靜態(tài)分析前先全部編譯一次,就不會(huì)出現(xiàn)找不到依賴模塊的情況.

Android整體編譯完成之后,在Android的源代碼目錄下編輯build/envsetup.sh下按照代碼2進(jìn)行編輯.修改--use-analyzer參數(shù)后面的路徑,更新為修改過的Clang程序的二進(jìn)制文件.

Android源代碼的工具鏈自帶了一套Clang3.3編譯前端,但是其版本太低,需要如代碼 3 里所示,修改/prebuilts/misc/linux-x86/analyzer/bin/ccc-analyzer文件,做下列兼容工作,否則改進(jìn)的Clang3.8無法正常運(yùn)行.其主要操作是:通過參數(shù)指定Clang3.8使用新加入的stp約束求解器,并且替換一些傳遞的過時(shí)的命令行參數(shù).

?

push @Args,“-Xclang”,“-analyzer-viz-egraph-ubigraph”;}+ //強(qiáng)制Clang編譯器使用本實(shí)驗(yàn)新加入的stp求解器+ push @Args,“-Xanalyzer”,“-analyzer-constraints=stp”; my$AnalysisArgs = GetCCArgs(“--analyze”,@Args); @CmdArgs =@$AnalysisArgs;+ //對(duì)參數(shù)進(jìn)行修改,以適應(yīng)新的Clang編譯器+ my @NewCmdArgs;+ foreach my $one (@CmdArgs){+ if($one eq “-Qignore-c-std-not-allowed-with-cplusplus”+ || $one eq “-fobjc-default-synthesize-properties”+ || $one eq “-fno-cxx-missing-return-semantics”)+ {next;}+ if($one eq “-disable-global-ctor-const-promotion”){+ push(@NewCmdArgs,“-disable-cgp-ext-ld-promotion”);+ next;+ }

$one);+ @CmdArgs = @NewCmdArgs;

代碼4.替換新的Clang編譯前端if($pid == 0){ close FROM_CHILD; open(STDOUT,“>&”,*TO_PARENT); open(STDERR,“>&”,*TO_PARENT);+ //置為實(shí)驗(yàn)修改的Clang的二進(jìn)制的地址+ $Cmd = “xxx”;exec $Cmd,@CmdArgs; }

再如代碼4所示,修改/prebuilts/misc/linux-x86/analyzer/bin/ccc-analyzer文件,修改內(nèi)部使用的$Cmd變量.從而完成對(duì) Android 源碼的修改.此時(shí),已經(jīng)可以使用Clang3.8正常編譯分析Android系統(tǒng)源代碼.

4.2 添加stp約束求解器

首先,安裝 stp約束求解庫(kù),需要安裝 minisat庫(kù)和 stp 庫(kù).然后,進(jìn)入 llvm 源碼,在 tools/clang/lib/Static-Analyzer/Core/目錄下仿照現(xiàn)有的RangeConstraint-Manager.cpp編寫調(diào)用stp求解器的STPConstraint-Manager.cpp,并對(duì)外提供接口CreateSTPConstraint-Manager返回STPConstraintManager類的實(shí)例供靜態(tài)分析核心使用.

STPConstraintManager.cpp可以參考網(wǎng)絡(luò)上已有的樣例約束求解器代碼進(jìn)行修改,但是需要注意因?yàn)楸疚氖褂玫腃lang是新版的,必須注意代碼的兼容性問題(過時(shí)的接口、類或結(jié)構(gòu)體的成員的變動(dòng)),否則程序無法正常執(zhí)行.

最后,如代碼 5 所示,在 tools/clang/include/clang/StaticAnalyzer/Core/Analyses.def中加入如下一行聲明(注意要和STPConstraintManager類的接口Create-STPConstraintManager名稱相同),可以支持在命令行選擇實(shí)際使用的求解器(range求解器或者stp求解器),方便進(jìn)行對(duì)比實(shí)驗(yàn)分析.

代碼5.增加新的約束求解器ANALYSIS_CONSTRAINTS(STPConstraints,“stp”,“Use STP solver”,CreateSTPConstraintManager)

4.3 改進(jìn)Clang的Checker

如圖1所示,Clang編譯前端在靜態(tài)分析中,真正執(zhí)行缺陷判斷的是一系列的Checker.所以,為了增強(qiáng)Clang的靜態(tài)檢測(cè)能力,必須對(duì)Clang的一系列的Checker進(jìn)行增強(qiáng).

污點(diǎn)傳播部分,修改LLVM代碼里的toolsclanglibStaticAnalyzerCheckersGenericTaintChecker.cpp.這個(gè)Checker支持對(duì)C的函數(shù)進(jìn)行污點(diǎn)標(biāo)記和傳播,但是不支持對(duì)C++類的處理.對(duì)這個(gè)Checker進(jìn)行增強(qiáng),加入對(duì)C++類的判斷和處理.

因?yàn)锳ndroid系統(tǒng)代碼的復(fù)雜性,系統(tǒng)代碼對(duì)相當(dāng)一部分的文件和內(nèi)存操作都進(jìn)行了封裝.在對(duì)C++的成員方法進(jìn)行分析時(shí),可以對(duì)參數(shù)或者返回值進(jìn)行污點(diǎn)標(biāo)注.在實(shí)際標(biāo)注的時(shí)候可以根據(jù)待分析代碼的具體特征(例如:通用buffer緩沖類,及其他文件操作、內(nèi)存操作的通用類)添加特定處理,來進(jìn)行污點(diǎn)設(shè)定.開啟 (默認(rèn) C l a n g不開啟)這個(gè)修改過的Checker即可實(shí)現(xiàn)數(shù)據(jù)的污點(diǎn)標(biāo)記.

“敏感函數(shù)污點(diǎn)分析”部分可以通過表1中check::CheckPreCall搶在函數(shù)調(diào)用之前,進(jìn)行分析.“污點(diǎn)數(shù)據(jù)類型轉(zhuǎn)換”可以通過check::CheckPreStmt進(jìn)行攔截判斷,通過對(duì)Expr的判斷,抽取其中的隱式轉(zhuǎn)換和顯式轉(zhuǎn)換,進(jìn)行分析.“分支條件判斷污點(diǎn)”可以通過check::CheckBranchCondition對(duì)條件分支進(jìn)行攔截,并對(duì)其中的Stmt進(jìn)行判斷.

表1 Clang 的路徑敏感分析接口

圖2中的“溢出判斷”可以通過Clang內(nèi)置的SValBuilder類的evalBinOpNN方法對(duì)污點(diǎn)變量的范圍進(jìn)行估計(jì),測(cè)試污點(diǎn)變量是否經(jīng)過正確約束.

圖2中的“規(guī)則判斷”則可以通過ASTContext類的getParents(node)方法獲取父節(jié)點(diǎn),或者通過node本身自帶的各種方法獲取其子結(jié)點(diǎn).甚至可以使用Clang內(nèi)置的RecursiveASTVisitor類實(shí)現(xiàn)對(duì)某個(gè)結(jié)點(diǎn)的子結(jié)點(diǎn)進(jìn)行自動(dòng)遞歸查詢.

4.4 漏洞代碼的特征分析及處理

代碼6展示了CVE-2015-1538的部分補(bǔ)丁.

代碼6.CVE-2015-1538部分補(bǔ)丁代碼mTimeToSampleCount = U32_AT(&header[4]);- uint64_t allocSize = mTimeToSampleCount * 2 * sizeof(uint32_t);+ uint64_t allocSize = mTimeToSampleCount * 2 *(uint64_t)sizeof(uint32_t);

代碼6中的缺陷存在著固定的模式:污點(diǎn)數(shù)據(jù)由uint32類型參與運(yùn)算提升為uint64類型,但程序員沒有意識(shí)到溢出發(fā)生在類型的隱式轉(zhuǎn)換之前.所以引入了潛在的溢出風(fēng)險(xiǎn),故補(bǔ)丁加入了強(qiáng)制轉(zhuǎn)換.

但是,代碼6里的補(bǔ)丁仍舊是錯(cuò)誤的！這導(dǎo)致了后序的漏洞CVE-2015-6601.仔細(xì)觀察代碼6中的補(bǔ)丁,程序員的補(bǔ)丁里顯然意識(shí)到了污點(diǎn)數(shù)據(jù)隱式轉(zhuǎn)換的危險(xiǎn)性,但是程序員忘記了計(jì)算是從左到右執(zhí)行的.強(qiáng)制轉(zhuǎn)換太遲了,污點(diǎn)數(shù)據(jù)仍舊可以先溢出,再提升類型.

如代碼6所示,U32_AT是libstagefright從緩沖區(qū)讀取數(shù)據(jù)的公共方法,類似的還有U16_AT、U64_AT.U32_AT函數(shù)會(huì)觸發(fā)圖2中的“敏感函數(shù)污點(diǎn)標(biāo)記”,使mTimeToSampleCount變量被標(biāo)記.代碼6中對(duì)allocSize的賦值操作中,實(shí)際上發(fā)生了類型提升(未打補(bǔ)丁是隱式提升,打了錯(cuò)誤的補(bǔ)丁是顯式提升).如果表達(dá)式中包含污點(diǎn)數(shù)據(jù)且存在類型提升,則Chekcer觸發(fā)圖2中的“污點(diǎn)數(shù)據(jù)類型轉(zhuǎn)換”會(huì)對(duì)其中的類型轉(zhuǎn)換進(jìn)行檢查.

代碼7展示了CVE-2015-6604的部分補(bǔ)丁.

代碼7.CVE-2015-6604部分補(bǔ)丁代碼return false;}- if (offset + dataSize + 10 > mSize){+ if (dataSize > mSize-10- offset){return false;}

代碼7中的缺陷存在著固定的模式:在一個(gè)條件分支語句中,程序員忽視了污點(diǎn)數(shù)據(jù)的存在,過分相信變量,直接讓污點(diǎn)數(shù)據(jù)參與了計(jì)算,之后再參與比較判斷.

如代碼 7所示,其中 dataSize的數(shù)據(jù),由 U32_AT方式獲取,故被標(biāo)記為污點(diǎn)數(shù)據(jù).但是在if條件判斷語句中,因?yàn)闂l件判斷表達(dá)式含有污點(diǎn)數(shù)據(jù),故觸發(fā)圖2中的“分支條件判斷污點(diǎn)”,對(duì)條件表達(dá)式進(jìn)行求值分析.

4.5 Clang的報(bào)告生成

在4.3章中使用Clang的Checker對(duì)待檢測(cè)代碼進(jìn)行分析之后,如果發(fā)現(xiàn)潛在的問題,則使用Clang自帶的BugReport進(jìn)行風(fēng)險(xiǎn)代碼的報(bào)告.通過定義一個(gè)自定義BugReport,可以實(shí)現(xiàn)特定格式內(nèi)容的Bug報(bào)告.在分析結(jié)束之后,通過scan-view命令打開分析報(bào)告網(wǎng)頁(yè),對(duì)分析結(jié)果進(jìn)行查看.

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

5.1 試驗(yàn)環(huán)境

本文使用 Ubuntu16.04 LTS X64 操作系統(tǒng),處理器 Intel酷睿 i7 4750HQ(3.2 GHz),16 GB 內(nèi)存,80 GB交換分區(qū),1000 GB 機(jī)械硬盤.基于 Clang3.8 進(jìn)行測(cè)試修改.靜態(tài)分析期間,不同時(shí)運(yùn)行其他程序,以免影響時(shí)間和內(nèi)存使用的實(shí)驗(yàn)結(jié)果.

Clang運(yùn)行參數(shù)方面,除了第3章節(jié)所做的代碼修改和實(shí)驗(yàn)過程中輸入的動(dòng)態(tài)參數(shù),其余配置保持默認(rèn)參數(shù)不變.因?yàn)榉?hào)執(zhí)行會(huì)出現(xiàn)路徑爆炸問題,Clang會(huì)使用一個(gè)默認(rèn)最大循環(huán)執(zhí)行次數(shù)來進(jìn)行限制,默認(rèn)值是4,本實(shí)驗(yàn)不修改.

5.2 使用測(cè)試集對(duì)改進(jìn)后的Clang進(jìn)行驗(yàn)證

經(jīng)過改進(jìn)的Clang不能直接用于Android系統(tǒng)的代碼分析,需要首先確保修改的正確性,保證改進(jìn)后的Clang編譯前端本身沒有邏輯錯(cuò)誤.一個(gè)錯(cuò)誤的Clang編譯前端在分析Android源代碼時(shí)的結(jié)果是不可信的.而改進(jìn)的Clang編譯前端的代碼修改集中在符號(hào)執(zhí)行和整形溢出檢測(cè)上,所以需要一組整形溢出測(cè)試集驗(yàn)證Clang的符號(hào)執(zhí)行精度和整形溢出檢測(cè)能力.

測(cè)試集的選取,選用的是從NIST網(wǎng)站下載的美國(guó) NSA (National security agency)開發(fā)的 Juliet_Test_Suite[24]測(cè)試集.Juliet_Test_Suite 測(cè)試集包含多種CWE (Common weakness enumeration)[16]類型的常見漏洞代碼.本實(shí)驗(yàn)選取其中的“CWE190_Integer_Overflow”測(cè)試集.其測(cè)試集下總共有5種類型的子測(cè)試集,分別編號(hào) S01,S02,S03,S04,S05.

通過特定的宏定義,可以調(diào)整測(cè)試集的檢測(cè)特性.如:只檢測(cè)存在有安全缺陷的函數(shù)、只檢測(cè)不存在安全缺陷的函數(shù)、檢測(cè)全部函數(shù).表2顯示了5個(gè)子測(cè)試集的函數(shù)用例數(shù)量.

表2 測(cè)試集溢出漏洞用例數(shù)量 (個(gè))

測(cè)試過程中,采用子測(cè)試集逐個(gè)進(jìn)行測(cè)試的方式執(zhí)行.單個(gè)子測(cè)試集在測(cè)試的時(shí)候,分為六次測(cè)試.前兩次使用未修改的原生的Clang且使用自帶的range約束求解器分別測(cè)試安全函數(shù)和不安全函數(shù).中間兩次使用改進(jìn)的Clang且使用自帶的range約束求解器分別測(cè)試安全函數(shù)和不安全函數(shù),后兩次使用改進(jìn)的Clang且使用新加入的stp約束求解器分別測(cè)試安全函數(shù)和不安全函數(shù).運(yùn)行靜態(tài)分析的時(shí)候,記錄分析所需要的時(shí)間,并分析所得到的結(jié)果,測(cè)試所需時(shí)間如表3所示.其中,good_origin_range 指原生的 Clang 使用自帶的range求解器只檢測(cè)安全函數(shù),good_improved_range指改進(jìn)的Clang使用自帶的range求解器只檢測(cè)安全函數(shù),good_improved_stp指改進(jìn)的Clang使用新加入的stp求解器只檢測(cè)安全函數(shù).bad_origin_range,bad_improved_range,bad_improved_stp 指相同的情況下只檢測(cè)不安全函數(shù).

表3 靜態(tài)分析所需時(shí)間 (秒)

通過表3分析發(fā)現(xiàn),不管是只檢測(cè)安全函數(shù)還是只檢測(cè)不安全函數(shù),在都使用自帶的range求解器的情況下,改進(jìn)的Clang比原生的Clang檢測(cè)時(shí)間增長(zhǎng)了約兩倍,這是因?yàn)楦倪M(jìn)的Clang增加了污點(diǎn)傳播等更多的檢測(cè)規(guī)則,導(dǎo)致檢測(cè)時(shí)間的增大.同樣是改進(jìn)的Clang,使用新增加的stp求解器比使用range求解器耗費(fèi)的時(shí)間都要多,但是基本不多于10%,這是因?yàn)閟tp的求解能力更強(qiáng),規(guī)則更復(fù)雜,導(dǎo)致了耗費(fèi)時(shí)間的增加.

表4 中“good_origin_range”和“bad_origin_range”分別指原生Clang使用自帶的range求解器測(cè)試安全用例和不安全用例的情況.通過測(cè)試發(fā)現(xiàn),基本只能找到“Dead assignment”,“Dead initialization”,“Memory leak”這三種錯(cuò)誤.不管是安全測(cè)試用例還是不安全測(cè)試用例,均無法檢出任何溢出漏洞.這是因?yàn)樵腃lang本身無對(duì)應(yīng)的檢測(cè)規(guī)則.

表4 檢出溢出類型漏洞數(shù)量 (個(gè))

表4 中的“good_improved_range”和“good_improved_stp”分別指改進(jìn)的Clang使用自帶range求解器或stp求解器分別對(duì)安全用例的檢測(cè)情況.改進(jìn)的Clang,因?yàn)闄z測(cè)規(guī)則的增加,已經(jīng)可以檢測(cè)溢出漏洞.但是,安全測(cè)試用例中是沒有不安全的用例的.所以,通過比較,在使用 range求解器的情況下,有超高的誤報(bào),而stp的誤報(bào)則是非常的低.具體原因是range求解器的能力過弱,很多復(fù)雜約束不能處理,導(dǎo)致實(shí)際上沒有成功加入約束條件,導(dǎo)致了大量的誤報(bào).其中誤報(bào)的數(shù)量甚至超過了測(cè)試用例的數(shù)量,一個(gè)原因是某些用例有多種測(cè)試方法,此外如圖2所示,改進(jìn)的Clang有3種觸發(fā)方式進(jìn)行缺陷分析,一個(gè)函數(shù)由若干行的代碼構(gòu)成,所以一個(gè)函數(shù)體可能檢出不少于1個(gè)漏洞.

不安全測(cè)試用例在源代碼的對(duì)應(yīng)代碼行的注釋中,進(jìn)行了標(biāo)注.表4 中的“bad_improved_range”和“bad_improved_stp”分別指改進(jìn)的Clang使用自帶range求解器或stp求解器分別對(duì)不安全用例的檢測(cè)情況.通過對(duì)測(cè)試報(bào)告的排查,stp求解器雖然檢出的結(jié)果比較少,但是非常準(zhǔn)確.range求解器檢出的結(jié)果存在大量的誤報(bào),將測(cè)試用例的源代碼中,沒有標(biāo)記為缺陷位置的代碼檢測(cè)為存在缺陷.

收集測(cè)試用例的靜態(tài)分析結(jié)果,同時(shí)收集靜態(tài)分析日志,結(jié)合在一塊進(jìn)行分析,可以得出結(jié)論:stp 求解器雖然在時(shí)間耗費(fèi)上比range求解器稍多,但是在約束求解精度上,stp求解器有很大的提高; 同時(shí)結(jié)合靜態(tài)分析日志和測(cè)試用例源代碼,對(duì)比stp求解器的約束區(qū)間,可以發(fā)現(xiàn)求解器計(jì)算出了正確約束區(qū)間.

5.3 使用改進(jìn)的Clang編譯前端對(duì)Android源碼進(jìn)行分析

參考第4節(jié)的“Android代碼靜態(tài)分析的實(shí)現(xiàn)”里的實(shí)現(xiàn),整個(gè)Android源代碼在編譯和修改完畢之后,運(yùn)行代碼8里的指令,即可使用改進(jìn)的Clang且使用stp約束求解器對(duì)Android源碼進(jìn)行靜態(tài)分析.

代碼8.執(zhí)行靜態(tài)分析$source build/envsetup.sh$lunch aosp_arm-eng$WITH_STATIC_ANALYZER=1 mmm model_path -B

本實(shí)驗(yàn)主要通過“WITH_STATIC_ANALYZER=1 mmm frameworks/av/media/libstagefright/-B”對(duì)Android源代碼的libstagefright模塊進(jìn)行分析.通過對(duì)Android不同版本的源碼進(jìn)行靜態(tài)分析,對(duì)于未打補(bǔ)丁的源碼可以找出以下高危漏洞,其漏洞CVE編號(hào)分別如下:CVE-2015-1538,CVE-2016-6601,CVE2015-3832,CVE-2015-3831,CVE-2015-6604.

圖3 CVE-2015-1538 漏洞檢測(cè)結(jié)果界面

5.4 分析過程的時(shí)間復(fù)雜度、空間復(fù)雜度及優(yōu)化

本實(shí)驗(yàn)的分析工具在時(shí)間復(fù)雜度上耗時(shí)較大,分析簡(jiǎn)單的libmedia模塊需要十幾分鐘,但是分析復(fù)雜的libstagefright模塊就需要幾十個(gè)小時(shí).通過使用linux下的perf性能調(diào)優(yōu)工具對(duì)分析過程(不能直接分析第5.3節(jié)中的mmm命令,分析mmm函數(shù)解析后的命令)進(jìn)行分析,發(fā)現(xiàn)耗時(shí)的TOP-50函數(shù)均是來自libstp.so和libminisat.so里的函數(shù),兩個(gè)庫(kù)文件里的函數(shù)總共占用了95%以上的運(yùn)行時(shí)間.其中l(wèi)ibstp.so是分析工具所依賴的STP求解器的庫(kù)文件,libminisat.so是libstp.so所依賴的庫(kù)文件.運(yùn)行時(shí)間主要耗費(fèi)在求解表達(dá)式.

本實(shí)驗(yàn)的分析工具在空間復(fù)雜度上耗費(fèi)也較大.如分析 libmedia 模塊需要 1–2 GB 內(nèi)存,分析 libstagefright模塊需要 2–4 GB 內(nèi)存,短時(shí)間會(huì)使用 16 GB 以上內(nèi)存.通過使用linux下的gdb和valgrind內(nèi)存分析工具對(duì)分析過程進(jìn)行分析,主要發(fā)現(xiàn)libstp.so庫(kù)文件與加入的STP求解器代碼存在內(nèi)存泄露問題,其中存在少數(shù)沒及時(shí)釋放的大內(nèi)存塊,導(dǎo)致了大量的內(nèi)存占用.

針對(duì)時(shí)間復(fù)雜度和空間復(fù)雜度的問題,對(duì)本實(shí)驗(yàn)的分析工具進(jìn)行對(duì)應(yīng)的優(yōu)化,在加入的STP求解器的代碼部分,加入了遺漏的釋放資源的代碼,降低內(nèi)存占用,減少了部分內(nèi)存泄露.同時(shí)對(duì)Checker里的檢測(cè)代碼進(jìn)行優(yōu)化,盡量用循環(huán)來取代遞歸,同時(shí)將符號(hào)執(zhí)行里的污點(diǎn)數(shù)據(jù)按照符號(hào)執(zhí)行地址存放在公共map數(shù)據(jù)結(jié)構(gòu)里,進(jìn)行加速,以此節(jié)約內(nèi)存和時(shí)間.

6 結(jié)語

本文提出了使用改進(jìn)的Clang對(duì)Android源代碼進(jìn)行靜態(tài)分析的研究和實(shí)現(xiàn),通過新增Clang的約束求解器并對(duì)靜態(tài)檢測(cè)功能進(jìn)行改進(jìn),實(shí)現(xiàn)了對(duì)Android部分類型漏洞的靜態(tài)分析檢測(cè),并成功檢測(cè)到部分漏洞.最終實(shí)現(xiàn)了可用的對(duì)Android源代碼進(jìn)行分析檢測(cè)的實(shí)用靜態(tài)分析工具.

但是分析工具自身還存在一些問題,例如:時(shí)間耗費(fèi)較長(zhǎng)、內(nèi)存耗費(fèi)較大,經(jīng)過第5.4節(jié)的優(yōu)化,解決了部分問題,但是內(nèi)存泄露問題沒有徹底去除,耗時(shí)仍舊偏長(zhǎng); 此外靜態(tài)分析自身的符號(hào)執(zhí)行存在一定偏差,面對(duì)特別復(fù)雜的約束條件和調(diào)用過程,不能準(zhǔn)確地進(jìn)行約束求解.而且,圖2的“溢出判斷”中的判斷方法有些粗糙,容易造成漏報(bào),“溢出判斷”需要對(duì)加減乘除等各種情況進(jìn)行仔細(xì)地處理,這些處理需要大量的細(xì)節(jié)進(jìn)行完善.

1Dietz W,Li P,Regehr J,et al.Understanding integer overflow in C/C++.ACM Trans.on Software Engineering and Methodology (TOSEM),2015,25(1):2.

2Bush WR,Pincus JD,Sielaff DJ.A static analyzer for finding dynamic programming errors.Software-Practice &Experience,2000,30(7):775–802.

3Schmidt D,Steffen B.Program analysis as model checking of abstract interpretations.International Static Analysis Symposium.Pisa,Italy.1998.351–380.

4Cadar C,Dunbar D,Engler D.KLEE:Unassisted and automatic generation of high-coverage tests for complex systems programs.Proc.of the 8th USENIX Conference on Operating Systems Design and Implementation.San Diego,California,USA.2008.209–224.

5Kremenek T.Finding Software Bugs with the Clang Static Analyzer.California:Apple Inc,2008.

6Xu ZX,Kremenek T,Zhang J.A memory model for static analysis of C programs.International Symposium on Leveraging Applications of Formal Methods,Verification and Validation.Heraklion,Crete,Greece.2010.535–548.

7Khedker U,Sanyal A,Sathe B.Data Flow Analysis:Theory and Oractice.Boca Raton,FL:CRC Press,2009.

8Xu ZB,Zhang J,Xu ZX.Melton:A practical and precise memory leak detection tool for C programs.Frontiers of Computer Science,2015,9(1):34–54.[doi:10.1007/s11704-014-3460-8]

9Reps T,Horwitz S,Sagiv M.Precise interprocedural dataflow analysis via graph reachability.Proc.of the 22nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages.San Francisco,California,USA.1995.49–61.

10Liu T,Huuck R.Case study:Static security analysis of the android goldfish kernel.International Symposium on Formal Methods.Oslo,Norway.2015.589–592.

11Muntean P,Rahman M,Ibing A,et al.SMT-constrained symbolic execution engine for integer overflow detection in C code.Proc.of 2015 Information Security for South Africa(ISSA).Johannesburg,Azania.2015.1–8.

12Wang TL,Wei T,Lin ZQ,et al.IntScope:Automatically detecting integer overflow vulnerability in X86 binary using symbolic execution.Proc.of the Network and Distributed System Security Symposium.San Diego,California,USA.2009.

13Cadar C,Godefroid P,Khurshid S,et al.Symbolic execution for software testing in practice:Preliminary assessment.Proc.of the 33rd International Conference on Software Engineering.Honolulu,HI,USA.2011.1066–1071.

14Sui YL,Yu D,Xue JL.Static memory leak detection using full-sparse value-flow analysis.Proc.of the 2012 International Symposium on Software Testing and Analysis.Minneapolis,MN,USA.2012.254–264.

15Li L,Cifuentes C,Keynes N.Practical and effective symbolic analysis for buffer overflow detection.Proc.of the 18th ACM SIGSOFT International Symposium on Foundations of Software Engineering.Santa Fe,New Mexico,USA.2010.317–326.

16Sui YL,Xue JL.SVF:Interprocedural static value-flow analysis in LLVM.Proc.of the 25th International Conference on Compiler Construction.Barcelona,Spain.2016.265–266.

17Enck W,Gilbert P,Han S,et al.TaintDroid:An informationflow tracking system for realtime privacy monitoring on smartphones.ACM Trans.on Computer Systems (TOCS),2014,32(2):5.

18Arzt S,Rastofher S,Fritz C,et al.Flowdroid:Precise context,flow,field,object-sensitive and lifecycle-aware taint analysis for android apps.ACM SIGPLAN Notices,2014,49(6):259–269.[doi:10.1145/2666356]

19Horváth G,Pataki N.Clang matchers for verified usage of the C++ standard template library.Annales Mathematicae et Informaticae,2015,44:99–109.

20Android的全系統(tǒng)符號(hào)執(zhí)行工具-Android_S2E.http://www.infoq.com/cn/presentations/whole-system-symbol-Implementation-tools-android-s2e.[2017-01-05].

21Lattner C,Adve V.LLVM:A compilation framework for lifelong program analysis & transformation.Proc.International Symposium on Code Generation and Optimization.San Jose,CA,USA.2004.75–86.

22Spreitzenbarth M,Schreck T,Echtler F,et al.Mobilesandbox:Combining static and dynamic analysis with machine-learning techniques.International Journal of Information Security,2015,14(2):141–153.[doi:10.1007/s10207-014-0250-0]

23Zhang JX,Li ZJ,Zheng XC.PathWalker:A dynamic symbolic execution tool based on LLVM byte code instrumentation.International Symposium on Dependable Software Engineering:Theories,Tools,and Applications.Nanjing,China.2015.227–242.

24Software Assurance Reference Dataset.https://samate.nist.gov/SRD/testsuite.php.[2016-11-10].

Android Source Code Static Analysis Technology Based on Clang Compiler Front-Ends

CAO Yuan-Ye1,2,DING Li-Ping1

1(Lab of Fundamental Software,Institute of Software,Chinese Academy of Sciences,Beijing 100190,China)2(University of Chinese Academy of Sciences,Beijing 100049,China)

Android phones have a large market share in the world,and the third-party system based on Android-derived is also very popular.As the security issues appear in Android systems frequently,this paper uses Clang to compile Android source code for static analysis.This analysis extracts rules and models from published CVE vulnerabilities,and uses the improved Clang to statically analyze Android source code to detect potentially unsafe code snippets.During the analysis of the Android source code,the Clang static analyzer taints attack surface,and calls the new added STP constrained solver.Then it taints sensitive data through the symbolic execution,and makes taint analysis on the sensitive functions,sensitive operations,sensitive rules,finally reports unsafe code snippets if there are potential security risks.Through experimental analysis,this method can accurately identify unsafe source code snippets that exist in the Android source code with the same type of security risk,and this method can detect five high-risk CVE vulnerabilities in the libstagefright module.

Clang compiler; Android; static analysis; taint analysis; symbolic execution

曹原野,丁麗萍.基于Clang編譯前端的Android源代碼靜態(tài)分析技術(shù).計(jì)算機(jī)系統(tǒng)應(yīng)用,2017,26(10):1–10.http://www.c-s-a.org.cn/1003-3254/6013.html

國(guó)家高技術(shù)研究發(fā)展計(jì)劃(“863”計(jì)劃)(2015AA016003)

2017-01-16; 采用時(shí)間:2017-02-23