嵌入式C代碼釋放后重用缺陷檢測

王亞昕，李孝慶 ，伍高飛，唐士建，朱亞杰，董 婷

(1.北京空間機電研究所，北京，100094；2.西安電子科技大學(xué) 網(wǎng)絡(luò)與信息安全學(xué)院，陜西 西安 710071)

C語言是一種面向過程的通用程序設(shè)計語言。編譯系統(tǒng)的交叉編譯能力使得C語言能夠適用于ARM、C51等多種嵌入式體系架構(gòu)。由C語言編寫的嵌入式代碼廣泛應(yīng)用于操作系統(tǒng)內(nèi)核及驅(qū)動、應(yīng)用程序及代碼庫、單片機軟件等，其使用場景包括移動終端、IoT設(shè)備[1]、工控設(shè)施、航空航天系統(tǒng)[2]等。這對其安全性和可靠性提出了很高的要求。

因此，針對嵌入式C代碼中的缺陷進行及時檢測和修復(fù)極為重要。C代碼中的釋放后重用 (Use-after-Free，UaF) 缺陷極為常見且危害嚴重。雖然不同嵌入式平臺使用的動態(tài)內(nèi)存管理函數(shù)各不相同，但是UaF缺陷的成因是相同的，即C代碼在內(nèi)存釋放之后未將內(nèi)存指針清零，導(dǎo)致“野指針”留存，并在后續(xù)代碼執(zhí)行中繼續(xù)被用來進行相應(yīng)操作。Android手機所使用的嵌入式內(nèi)核驅(qū)動[3]就曾因一個UaF缺陷導(dǎo)致了華為、三星等諸多廠商的智能手機面臨極為嚴重的安全風(fēng)險，惡意應(yīng)用可獲得手機的完全控制權(quán)。這一案例充分證明了嵌入式C代碼中UaF缺陷的危害性。

現(xiàn)有的嵌入式代碼缺陷檢測工作未能有效支持UaF缺陷，在一般計算機系統(tǒng)中較為成熟的自動化UaF檢測工具又不能支持復(fù)雜多樣的嵌入式平臺。因此，筆者設(shè)計了一套支持不同嵌入式平臺的靜態(tài)代碼分析工具，實現(xiàn)了對于C代碼UaF缺陷的自動化檢測。主要貢獻如下：

(1) 實現(xiàn)了基于內(nèi)存指向的、支持數(shù)據(jù)結(jié)構(gòu)操作的、上下文和路徑約束敏感的過程間數(shù)據(jù)流分析。

(2) 歸納了UaF缺陷代碼的數(shù)據(jù)操作和傳遞的特征，并基于數(shù)據(jù)流分析開展污點追蹤。

(3) 利用大量測試用例與大型嵌入式項目代碼開展驗證性實驗，論證了該工具在發(fā)現(xiàn)UaF缺陷的有效性、可靠性及準確性，證明了其在不同架構(gòu)平臺、大規(guī)模代碼項目上的適用性。

1 相關(guān)工作

C語言具有廣泛而復(fù)雜的應(yīng)用場景。對C代碼UaF缺陷開展檢測有助于提高其在各種應(yīng)用場景中的可靠性與安全性。現(xiàn)有的代碼缺陷檢測技術(shù)多針對操作系統(tǒng)或應(yīng)用程序等單一場景開展研究，針對嵌入式C代碼UaF的檢測未能得到有效支持。

1.1 嵌入式代碼缺陷檢測

為了有效利用嵌入式設(shè)備的有限計算資源，通常情況下嵌入式系統(tǒng)對于代碼復(fù)雜度有較高限定，并會以此來評價軟件的代碼質(zhì)量。評價方法所涵蓋的軟件度量單元包括控制流節(jié)點度量、扇入扇出度量、循環(huán)深度度量、圈復(fù)雜度等[4]。Mccabe公司的ASM8086，奧吉通公司的CRESTS/ATAT等工具能對此類問題開展基于代碼規(guī)范的自動化分析。

從代碼缺陷角度來看：在高安全性高穩(wěn)定性要求的領(lǐng)域，對于嵌入式軟件的堆棧使用情況的安全測試必不可少，基于匯編代碼的堆棧溢出靜態(tài)測試方案可以實現(xiàn)對此類缺陷的自動化測試[5]；具體到航天器軟件產(chǎn)品，其常見的代碼缺陷包括變量未初始化、數(shù)組越界、整型溢出、操作符優(yōu)先級錯誤、循環(huán)變量錯誤等，使用代碼分析可實現(xiàn)相關(guān)缺陷檢測[6]。

1.2 UaF缺陷檢測

常見的C語言UaF檢測工作主要針對計算機系統(tǒng)及其程序，分為動態(tài)執(zhí)行和靜態(tài)分析兩種方法。

動態(tài)執(zhí)行以Fuzz測試[7]為代表，利用惡意構(gòu)造的測試用例觸發(fā)并捕獲目標代碼中的異常行為。主要難點在于如何捕獲UaF代碼異常。對于源代碼，可利用編譯框架提供的ASAN選項，進行異常檢測代碼的插裝[8-9]；對于二進制代碼，通常需要仿真調(diào)試或者二進制指令插裝[10]的方式實現(xiàn)異常監(jiān)控。動態(tài)執(zhí)行還需解決生成測試用例以觸發(fā)更多代碼分支的問題[11-12]。

靜態(tài)分析不需運行被測代碼。對于源代碼，通常轉(zhuǎn)換為中間語言(Intermediate Representation，IR)開展分析，現(xiàn)有工作涵蓋了單線程應(yīng)用程序[13]和多線程內(nèi)核驅(qū)動[14]中UaF缺陷的檢測方法。針對二進制的靜態(tài)分析則需結(jié)合反匯編工具[15]。靜態(tài)分析的優(yōu)勢在于理論上能覆蓋代碼所有執(zhí)行路徑，漏報率低；缺點在于誤報率較高，其主要原因是無效的代碼執(zhí)行路徑未被識別，通常會引入符號執(zhí)行[16]工具以降低誤報。

1.3 小 結(jié)

綜合分析相關(guān)工作，現(xiàn)有的嵌入式代碼缺陷檢測方案并不能實現(xiàn)有效的UaF檢測；而針對一般計算機C程序的UaF檢測工作雖然已有較多，但其在復(fù)雜多樣的嵌入式平臺并不完全適用。因此，設(shè)計一種適配多類型嵌入式平臺的UaF檢測工具是十分必要的。

2 UaF缺陷檢測方案設(shè)計

靜態(tài)代碼分析能更好適應(yīng)于多種嵌入式平臺，而動態(tài)執(zhí)行技術(shù)則受限于代碼執(zhí)行和調(diào)試環(huán)境，適用場景有限。因此，選擇靜態(tài)代碼分析中的污點追蹤技術(shù)開展UaF自動化檢測。由于C語言是一種直接面向內(nèi)存的編程語言，其污點分析工具在設(shè)計與實現(xiàn)過程中比其他語言更為復(fù)雜，須支持：① 內(nèi)存指向分析，跟蹤內(nèi)存指針在寄存器和內(nèi)存之間的傳遞，記錄指針變量指向關(guān)系；② 數(shù)據(jù)結(jié)構(gòu)內(nèi)部變量追蹤，數(shù)據(jù)結(jié)構(gòu)是C語言中極為重要和廣泛應(yīng)用的數(shù)據(jù)格式；③ 跨函數(shù)的過程間追蹤，追蹤函數(shù)調(diào)用和返回過程的數(shù)據(jù)傳遞；④ 上下文敏感，以處置基于代碼上下文進行選擇性變量賦值的操作；⑤ 路徑約束敏感，記錄約束條件并求解，防止無效路徑。

基于上述分析，設(shè)計如圖 1所示的系統(tǒng)架構(gòu)。整個分析過程如下：

(1) 將C源碼文件編譯為IR代碼。

(2) 開展直接函數(shù)調(diào)用圖分析。

(3) 開展跨函數(shù)控制流分析。

(4) 開展跨函數(shù)數(shù)據(jù)流分析，并特別針對函數(shù)指針、內(nèi)存指針和路徑約束變量進行數(shù)據(jù)追蹤。

(5) 基于數(shù)據(jù)流追蹤，實現(xiàn)間接函數(shù)調(diào)用分析、指向分析和路徑約束分析。

(6) 基于UaF漏洞特征開展污點追蹤。

可以看出，全面的數(shù)據(jù)追蹤是進一步開展指向分析、污點追蹤和路徑約束分析的基礎(chǔ)。為了實現(xiàn)準確、全面的數(shù)據(jù)流分析，定義了如表1中所示的存儲單元和存儲元素，每種存儲單元可存儲任意一種存儲元素。

表1 數(shù)據(jù)存儲單元與數(shù)據(jù)存儲元素

3 UaF缺陷檢測工具實現(xiàn)

數(shù)據(jù)流分析是實現(xiàn)整個缺陷檢測的核心，以此為基礎(chǔ)可開展全面有效的污點追蹤技術(shù)，從而準確判定UaF缺陷是否存在。靜態(tài)代碼分析中常見的路徑爆炸、誤報率高等難點也得到了有效處置。

表2 針對特定LLVM IR語句進行數(shù)據(jù)流分析

3.1 數(shù)據(jù)流分析

數(shù)據(jù)流分析采用正向分析，沿著執(zhí)行路徑分析每條語句是否會引起：① 存儲單元之間傳遞了存儲元素；② 新創(chuàng)建的存儲元素被存入了目的存儲單元；③ 存儲單元中的原有存儲元素遭到了覆蓋。表2展示了不同LLVM IR語句所導(dǎo)致的存儲元素從源存儲單元向目的存儲單元的數(shù)據(jù)傳遞關(guān)系。

3.2 污點追蹤

結(jié)合UaF代碼行為特征的污點追蹤技術(shù)可實現(xiàn)有效的缺陷檢測。算法1展示了污點源的判定規(guī)則。當(dāng)一條指令進行內(nèi)存釋放，分析代碼將獲取內(nèi)存指針對應(yīng)的內(nèi)存對象，并為其添加釋放標簽。算法2展示了污點陷入的判定規(guī)則。首先獲取語句使用的變量集合，逐一分析其是否為內(nèi)存指針，并且指向已添加了釋放標簽的內(nèi)存對象，如是則判斷是否為安全敏感的UaF操作。為了實現(xiàn)完整的污點追蹤：在數(shù)據(jù)結(jié)構(gòu)內(nèi)部變量的獲取時，需進行污點傳遞；在內(nèi)存對象不被其他內(nèi)存指針引用時，需進行污點消除。

算法1內(nèi)存釋放的標簽添加過程。

輸入1 待分析函數(shù)調(diào)用指令callInst。

輸入2 代碼狀態(tài)記錄analysisState。

返回值：更新后的代碼狀態(tài)記錄analysisState。

① func =獲取callInst 被調(diào)函數(shù)

② if(func不是內(nèi)存釋放函數(shù))

③ 返回analysisState

④ freedOpe =獲取被釋放的目的內(nèi)存寄存器

⑤ freedPointer =從analysisState 中查詢freedOpe 存儲的值

⑥ freedMemoryBlock=從analysisState 中查詢freedPointer 指針指向的內(nèi)存塊

⑦ freeTag =創(chuàng)建記錄了釋放操作的內(nèi)存塊標簽

⑧ 向analysisState 中添加記錄：freedMemoryBlock 被打上了freeTag 標簽

⑨ 返回analysisState

算法2釋放后重用導(dǎo)致污點陷入的判定。

輸入1 待分析指令inst。

輸入2 代碼狀態(tài)記錄analysisState。

返回值：更新后的代碼狀態(tài)記錄analysisState。

① allOpes =獲取inst 的所有操作數(shù)寄存器

② for(依次取出allOpes 里每一個的操作數(shù)寄存器)

③ ope=本次取出的操作數(shù)寄存器

④ value=從analysisState 中查詢ope 存儲的值

⑤ if(value不是一個內(nèi)存指針

⑥ 進行下一輪循環(huán)

⑦ memoryBlock=從analysisState 中查詢value 代表的內(nèi)存塊

⑧ hasFreeTag=從analysisState 中查詢memoryBlock 是否有內(nèi)存釋放標簽

⑨ if (hasFreeTag == false)

⑩ 進行下一輪循環(huán)

3.3 技術(shù)難點與解決方案

在工具實現(xiàn)過程中面臨著靜態(tài)代碼分析工具普遍存在的一些難點。文中以降低漏報率、適度容忍誤報率為原則，對這些難點設(shè)計實現(xiàn)了解決方案。

(1) 函數(shù)調(diào)用圖不完善。直接函數(shù)調(diào)用分析無法涵蓋復(fù)雜代碼中基于函數(shù)指針進行間接調(diào)用的情況。文中設(shè)計了針對函數(shù)指針這一特殊的常量型存儲元素的追蹤方法，補全了函數(shù)調(diào)用圖中的間接函數(shù)調(diào)用路徑，從而提高了分析過程的準確性和全面性。

(2) 控制流路徑爆炸。路徑爆炸問題主要來源于循環(huán)語句、遞歸調(diào)用等。通過限制基礎(chǔ)代碼塊在當(dāng)前函數(shù)分析過程中的分析次數(shù)、限定代碼執(zhí)行路徑上每個函數(shù)的被執(zhí)行次數(shù)的手段提高了測試的成功率，并進一步利用路徑約束求解降低進入無效代碼路徑的可能性，提高了測試準確性。

(3) 針對數(shù)組元素的數(shù)據(jù)流分析。如果在數(shù)組元素的數(shù)據(jù)訪問過程中索引值為符號值，則文中將嘗試統(tǒng)計目標數(shù)組中可訪問范圍內(nèi)的所有元素，并在后續(xù)分析中對于每種取值情況開展數(shù)據(jù)流分析，從而覆蓋所有可能的取值情況。這樣可確保數(shù)據(jù)流分析過程的全面性，降低漏報率。

(4) 起始函數(shù)設(shè)計與測試流程調(diào)控。對于一些測試目標，需為其創(chuàng)建虛擬的測試起始函數(shù)，實現(xiàn)測試過程調(diào)控。例如Linux內(nèi)核的seq_file文件操作接口，會利用代碼段 1的數(shù)據(jù)結(jié)構(gòu)對響應(yīng)函數(shù)接口進行設(shè)定。

代碼段 1 seq_file文件響應(yīng)函數(shù)的結(jié)構(gòu)定義如下：

① struct seq_operations {

② void * (*start) (struct seq_file *m，loff_t*pos)；

③ void (*stop) (struct seq_file *m，void *v)；

④ void * (*next) (struct seq_file *m，void *v，loff_t *pos)；

⑤ int (*show) (struct seq_file *m，void *v)；

⑥ }；

⑦ struct seq_operationstest_op；

假設(shè)測試目標為名為test_op的該數(shù)據(jù)結(jié)構(gòu)實例，則測試起始函數(shù)的設(shè)計如代碼段 2所示，從而模擬進行讀文件操作時的響應(yīng)流程。此方案可解決在多次內(nèi)核響應(yīng)過程中的代碼狀態(tài)存留問題，提高準確率。

代碼段 2 針對seq_file的測試起始函數(shù)如下：

① void TEST(struct seq_file *m，void *v，loff_t*pos){

② for(i=0；i< 2；i++){

③ test_op.start(m，pos)；

④ test_op.next(m，v，pos)；

⑤ test_op.show(m，v)；

⑥ test_op.stop(m，pos)；

⑦ }}

4 UaF缺陷檢測工具實驗驗證

UaF缺陷檢測工具實驗驗證分為兩個部分，第1部分通過自行編寫的和公開的測試用例集合(所用測試用例已開源：http：//dwz.date/dn35)，驗證該工具發(fā)現(xiàn)代碼安全問題的效果和準確性；第2部分則通過有真實漏洞編號的UaF案例，驗證該工具在大型項目上的應(yīng)用效果。

4.1 測試用例進行功能驗證

4.1.1 自有測試用例設(shè)計與實驗

在UaF缺陷檢測工具工具的實現(xiàn)過程中，同步編寫了自有測試用例，涵蓋了數(shù)據(jù)流、調(diào)用圖、控制流等多個方面。具體測試內(nèi)容包括：① 調(diào)用圖全面性測試，包括直接調(diào)用和間接調(diào)用；② 控制流分析，包括路徑分支、代碼循環(huán)；③ 數(shù)據(jù)流分析，包括面向局部變量、全局變量、數(shù)據(jù)結(jié)構(gòu)、數(shù)組元素的數(shù)據(jù)追蹤。圖2左側(cè)展示的為測試用例代碼，右側(cè)為測試結(jié)果。測試結(jié)果以基礎(chǔ)代碼塊為單位，"L：XX"代表源代碼行數(shù)，虛線框表示所屬函數(shù)。其中代碼塊標注：橢圓，代表分析起點；點狀，代表發(fā)生內(nèi)存申請；橫線，代表發(fā)生內(nèi)存釋放；豎線，代碼發(fā)生內(nèi)存重用。跳轉(zhuǎn)的標注：C(all) 代表函數(shù)調(diào)用；Y(es)和N(o)分別代表條件語句為是和否；括號中的編號則標注了代碼執(zhí)行流程。該結(jié)果直接、清晰地呈現(xiàn)了UaF缺陷觸發(fā)時的代碼執(zhí)行路徑。

④ void foo(int argc) {

⑤ char* buf=malloc(10)；

⑥ if(buf == NULL)

⑦ return；

⑧ buf[0]=100；

⑨ free(buf)；

⑩ if(buf != NULL)

(a)測試用例代碼

4.1.2 開源測試用例集實驗驗證

Juliet測試用例集是軟件保障參考數(shù)據(jù)庫中的一個公開測試樣本集 ，其中包含138個C代碼UaF缺陷樣本，每個文件代碼量為數(shù)百行。利用這些樣本開展了驗證性實驗。實驗結(jié)果如表3所示，證明了該工具能以較低的資源消耗完成準確、快速的UaF檢測。限于篇幅，不再對單個用例的測試結(jié)果展開分析。

表3 Juliet測試結(jié)果統(tǒng)計

4.2 大型嵌入式軟件系統(tǒng)實驗驗證

選取在嵌入式操作系統(tǒng)領(lǐng)域和應(yīng)用軟件領(lǐng)域有廣泛應(yīng)用的Linux操作系統(tǒng)內(nèi)核和OpenSSL安全通信程序進行驗證。實驗過程使用ThinkPad X1，處理器為英特爾I7-8 750H，設(shè)備擁有16 GB內(nèi)存。

4.2.1 針對嵌入式操作系統(tǒng)漏洞的實驗驗證

Linux內(nèi)核被廣泛應(yīng)用于嵌入式系統(tǒng)，其代碼量超過27 000 000行。在4.7.1版本之前的disk_seqf_stop函數(shù)存在UaF漏洞[17]。該函數(shù)是/proc/diskstats文件的內(nèi)核響應(yīng)接口，在內(nèi)存釋放后未對指針變量seqf->private進行清零，遺留了“野指針”，最終導(dǎo)致UaF觸發(fā)。測試過程參考4.3節(jié)編寫了針對性的測試起始代碼。

選擇Linux 4.7版本開展測試。實驗過程進行了38分11秒，完成了1 399 020條路徑組合的分析工作。在對無關(guān)函數(shù)調(diào)用進行了自動化“剪枝”后，得到了精簡版的測試結(jié)果，如圖3所示。結(jié)果顯示disk_seqf_stop函數(shù)中被釋放的內(nèi)存在disk_seqf_next函數(shù)中發(fā)生了重用。

根據(jù)縱線方框的標注，定位disk_seqf_next異常代碼，如代碼段3。此段代碼在第844行進行函數(shù)調(diào)用，將seqf->private作為調(diào)用參數(shù)，這一指針正是被disk_seqf_stop釋放的內(nèi)存。因此確認存在UaF缺陷。

代碼段 3 Linux內(nèi)核disk_seqf_next實現(xiàn)代碼如下：

839 static void *disk_seqf_next(struct seq_file *seqf，

void *v，loff_t *pos)

840 {

841 struct device *dev；

842

843 (*pos)++；

844 dev=class_dev_iter_next(seqf->private)；

…

此外，disk_seqf_start函數(shù)在第2次被調(diào)用的執(zhí)行路徑(編號為17-18的有向線段)與第1次調(diào)用時是顯著不同的。結(jié)合代碼段4中該函數(shù)的源碼，可看出成功發(fā)現(xiàn)了一條可避免在第2次被調(diào)用時seqf->private野指針被覆蓋的執(zhí)行路徑。這也驗證了此測試報告的準確性。

代碼段 4 disk_seqf_start實現(xiàn)代碼如下：

818 static void *disk_seqf_start(struct seq_file *seqf，…){

820 loff_t skip=*pos；

821 struct class_dev_iter *iter；

822 struct device *dev；

824 iter=kmalloc(sizeof(*iter)，GFP_KERNEL)；

825 if (!iter)

826 return ERR_PTR(-ENOMEM)；

827

828 seqf->private=iter；

…

圖3 Linux內(nèi)核UaF漏洞的測試結(jié)果

4.2.2 針對嵌入式應(yīng)用軟件的實驗驗證

OpenSSL是一款Linux嵌入式系統(tǒng)上廣泛使用的軟件，代碼量約為450 000行。其1.1.0a版本中存在一個嚴重的UaF缺陷[18]。實驗選取了針對漏洞版本開展測試，選取了以服務(wù)程序的讀狀態(tài)機實現(xiàn)函數(shù)read_state_machine為測試起始點。測試過程持續(xù)7分51秒，完成286 567條代碼執(zhí)行路徑分析。為了驗證結(jié)果準確性，設(shè)立了對比實驗，基于ASAN異常捕獲機制獲取缺陷動態(tài)觸發(fā)時的調(diào)用棧信息，如圖4所示。將其與圖5中的靜態(tài)分析結(jié)果比較，可發(fā)現(xiàn)兩者的結(jié)果相符合。

圖4 OpenSSL UaF漏洞動態(tài)觸發(fā)調(diào)用棧

圖5 OpenSSL軟件UaF漏洞測試結(jié)果

5 現(xiàn)有方法對比

在UaF的自動化缺陷檢測領(lǐng)域，靜態(tài)分析和動態(tài)測試是特點鮮明的兩種方法。兩者并沒有優(yōu)劣之分，只是因其特點的不同，有著各自的適用場景。表4中總結(jié)了在現(xiàn)有研究工作中具有代表性的檢測方法。

表4 現(xiàn)有UaF缺陷檢測方法對比

對比表4中各項工作可發(fā)現(xiàn)：動態(tài)測試環(huán)境更加適用于通用計算機代碼的缺陷檢測，該場景下的代碼執(zhí)行環(huán)境和異常捕獲機制均較為完善，但對嵌入式代碼言并不適用；二進制靜態(tài)分析工具受限于其依賴的反匯編工具和符號執(zhí)行工具的適用范圍，僅能支持部分嵌入式平臺上的缺陷檢測。理論上來講，源代碼分析工具最適用于嵌入式代碼UaF的檢測，但現(xiàn)有工作[13-14]不能實現(xiàn)文中全面的數(shù)據(jù)流分析，使得開展UaF代碼特征識別的過程中存在較高的誤報率和漏報率，檢測效果并不理想。

6 結(jié)束語

筆者提出了一種針對嵌入式C代碼的UaF缺陷檢測方法，并基于LLVM編譯框架編寫了自動化檢測工具，實現(xiàn)了針對操作系統(tǒng)、應(yīng)用程序、單片機程序等多種嵌入式代碼的UaF缺陷檢測。工具具有全面、準確的數(shù)據(jù)流分析能力，能夠針對UaF缺陷代碼特征開展污點追蹤，從而實現(xiàn)自動化缺陷檢測和報告輸出。驗證實驗在測試樣本集、嵌入式操作系統(tǒng)和應(yīng)用程序等多個目標上開展。實驗結(jié)果表明，文中方法能夠準確、高效地實現(xiàn)不同場景下UaF缺陷的自動化檢測，并且能適用于大規(guī)模嵌入式代碼項目。