基于配對函數調用場景的設備驅動漏洞檢測①

王 佳,翟高壽,劉 峰,李紅輝

(北京交通大學 計算機與信息技術學院,北京 100044)

設備驅動程序作為操作系統中的重要組成部分,占據了Linux內核源碼約70%的部分.2001年,Chou等人[1]最早通過將靜態分析器應用于Linux 1.0版本至2.4.1版本用以進行故障分析,研究表明驅動程序目錄包含的錯誤比內核中的其他目錄多達7倍.驅動程序相當于一個處于硬件和應用程序之間的軟件接口,它負責對硬件設備底層I/O操作進行管理,可以將其視為一種內核模塊.由于驅動代碼本身可能存在缺陷和漏洞,設備驅動代碼開發人員通過編譯檢查很難排查到一些特定條件下才會觸發的代碼錯誤[2].2011年,Chen等人[3]對Linux內核中的漏洞做了具體的分析歸納,主要問題表現為內核接口誤用、緩沖區溢出、空指針及指針錯誤、競爭與死鎖、內存資源操作不當等.其中內存資源操作類漏洞作為其中的一種主要安全威脅,嚴重時甚至可直接造成系統崩潰.

設備驅動程序一般會調用特定的內核接口函數來申請和釋放資源,我們可稱之為配對函數[4],這種將資源操作類函數以成對形式進行提取的概念最早來自于Engler等人提出的一種名為ECC[5]的方法,ECC可以提取源代碼中的配對函數信息,并相應地提取潛在地正常執行路徑上的路徑規則.目前對于這類函數的文檔描述極少,但由于其涉及到內存資源的相關操作,一旦出現資源操作的錯誤,將會危及整個操作系統的安全.因此對于這類函數的相關檢測和處理至關重要.

現有的主流Linux設備驅動程序分析方法主要有動態分析、靜態分析以及符號執行3種.在如今的程序分析技術路線中,現有的大多數漏洞檢測方法主要針對用戶模式下的內核API調用規則和資源檢測[6],很多方法并不能很好地應用于工作在內核模式下的設備驅動程序上.在程序的安全缺陷檢查方面,動態分析通常需要在源碼中結合程序插樁技術[7],在程序執行過程中依據制定的驗證規則,對執行的中間結果進行分析.Zhou等人開發的SafeDrive[8]原型工具在編譯驅動程序時,根據內核開發人員的注釋插入相應的檢查規則,然后在運行時驗證程序的安全性和完整性.動態分析不需要對源碼進行系統地分析,但也因此達不到較高的覆蓋程度,且一般情況動態分析下都依賴于真實的硬件,這為實時檢測帶來很多難度.靜態分析則與動態分析的分析方向不同,其滿足在不運行程序的情況下,通過各種詞法、語法分析等分析技術來檢測分析源程序的數據流或控制流.由于設備驅動程序源碼中存在較多的條件分支和循環語句,靜態分析可以滿足全覆蓋源碼的條件,不依賴于真實的硬件設備,無需考慮很多執行過程中的限制因素,但是Linux設備驅動的代碼結構十分龐大,去分析其中的源碼結構和庫函數也是一件費時費力的事.符號執行[9]的分析方法則是用符號值替代具體的程序變量,并對所有可能的執行路徑使用約束求解技術[10]生成特定的路徑約束條件,得到符合條件的程序執行路徑.Cadar等人開發的輕量級符號執行工具KLEE[11]可以基于LLVM[12]下的中間語言并對其進行符號執行,通過程序執行狀態的變化模擬真實程序的執行情況.路徑爆炸是符號執行分析技術中產生的一個最主要的問題,伴隨著符號執行分析技術的發展,如何更有效地減少路徑分支的指數增長情況,避免產生路徑爆炸的問題正成為研究熱門.

以上3類設備驅動程序的分析方法都不可能100%覆蓋所有潛在的安全漏洞.目前的設備驅動資源漏洞檢測工作大多基于編譯后的中間結果,耦合度和復雜程度高,獲取的信息不全面,給漏洞分析檢測任務帶來許多挑戰,并且基于編譯過程中的中間結果有時不能直觀反映出設備驅動程序各函數的執行情況.在本文的工作中,我們提出了基于配對函數調用場景的設備驅動漏洞檢測方法并設計實現PFED (Pair Function Extraction and Detection)原型,首先是提取配對函數時優化配對的規則,自動化提取結合手工分析驗證;隨后,在記錄配對函數各項參數和調用信息的基礎上,通過獲取驅動函數調用場景信息以更新配對函數在驅動函數執行路徑中調用的記錄;最終,結合調用場景驗證并檢測可能存在的內存資源的申請和釋放不匹配問題.

本文的主要貢獻有:預處理源碼并優化提取資源操作類配對函數的結果,在驅動程序配對函數的互斥語義上做了更進一步的擴展與驗證;提出構建配對函數調用場景的概念,用于完整記錄配對函數在執行路徑上的對應關系,對源碼的覆蓋程度更高;設計并實現了基于配對函數調用場景的設備驅動漏洞檢測原型,實驗結果表明,該方法更適用于對設備驅動程序的分析,同時進一步降低了漏報率、誤報率.

1 相關工作

1.1 靜態分析

目前大部分的研究工作主要集中在檢測設備驅動漏洞的緩沖區溢出、整數溢出等這些溢出問題上,kint[13]是一個用于檢測C語言源程序中出現的整數溢出錯誤的靜態分析工具,圖1是其原型架構設計的流程圖,通過對基于LLVM形成的中間語言和注釋信息的分析、約束求解過程來生成最終的錯誤報告,可用于分析Linux內核,協助內核開發工作人員檢測程序中出現的整數溢出錯誤.由于經歷了中間語言的重寫和各項元數據集中處理的復雜過程,最后獲取的生成約束表達式并不十分準確,kint分析得到的整數溢出漏洞結果中存在著較高的誤報率.除此以外,在設備驅動的資源操作類漏洞方面,目前開展的研究工作主要是針對內存資源泄露的檢測.

圖1 Kint原型架構設計

1.2 運行時分析

PairDyn[14]是由Bai等人提出的一種運行時分析檢測方法,用來檢測設備驅動程序中的資源申請和釋放的匹配.

圖2是PairDyn的架構設計圖,在驅動程序運行時,PairDyn根據插入的探針記錄下運行時的關鍵信息,如參數返回值、函數調用信息,再將這些信息與手動篩選得到的驅動程序配對函數記錄列表相匹配,獲取相應的測試用例,測試對于內存資源的申請是否有相應的釋放函數調用與其對應.PairDyn是通過人工方式選擇配對函數的,而人工方式可能會出現一些誤判和遺漏;只能在運行時檢查正常情況下的執行路徑,因此其不能覆蓋程序中的異常處理路徑以及條件分支路徑.

圖2 PairDyn架構設計

2 設備驅動漏洞檢測原型的構建

本文的主要目標是先從設備驅動源程序中提取出函數調用完整信息,優化迭代并最終提取出真正的資源操作相關配對函數,記錄這些函數的調用上下文場景,包括函數的主調函數、被調函數、參數返回值等有效信息.在全覆蓋驅動源碼分析的基礎上,獲取各對配對函數在驅動源程序的執行路徑分支層級上的調用關系是否匹配和對稱.圖3展示了PFED原型系統的設計,接下來將對該方法涉及到的一些重要部分進行介紹說明.

圖3 原型系統設計

3 設備驅動漏洞檢測原型的設計與實現

為實現PFED原型,首先要了解聲卡、網卡、USB等常用設備驅動的工作流程、功能模塊以及主要程序結構.根據幾個不同類型的典型設備驅動分析其源程序結構,由于設備驅動的源程序代碼結構較為復雜,代碼量龐大,為了更高效將驅動源程序中有用的函數信息提取出來,首先我們要預處理源程序中的部分信息,在源程序中略去大量注釋、無用的條件預編譯語句、全局變量定義、結構體定義、宏定義及調用等冗余信息.在分析設備驅動程序對內核函數的依賴接口時,主要篩選出頻繁與內核函數交互的設備驅動函數定義進行分析,首先手工分析總結出涉及到內存資源操作的一些內核函數并記錄,其次開始著手自動提取驅動源程序中涉及到這些內核函數的所有函數原型列表、相關參數、調用關系、調用層級、執行路徑等重要相關信息,綜合得出調用上下文場景.

整個原型的構建及實現過程簡要歸納說明如下:

1)分析內核模塊的依賴接口,來確定重點提取的內核函數列表;

2)預處理驅動源程序,略去大量無用信息,提取重點函數原型列表;

3)設計并自動化提取內存資源相關操作的配對函數,手工驗證總結、優化糾錯;

4)創建配對函數在調用層級、調用關系、調用路徑等信息的調用上下文場景;

5)根據配對函數原型列表及調用上下文場景驗證內存資源的申請釋放是否嚴格按層級性匹配.

3.1 配對函數提取

3.1.1 函數原型列表

本文使用C語言編寫設備驅動源程序預處理模塊,使后續需要進行深入分析的驅動函數提取工作變的更輕量級.主要設計的存放函數原型列表及相關信息的數據結構如下:

3.1.2 配對函數識別

如圖4所示,我們以Linux4.8.8版本內核下的pcnet32網卡驅動程序為例,在Linux內核機制中,每個網卡都由一個net_device結構來描述,pcnet32.c中的pcnet32_get_link()函數是用來判斷當前網絡連接狀態的驅動程序,當執行單元訪問共享資源之前,需要用729行的spin_lock_irqsave來保存中斷標志,給中斷當前的開啟或關閉狀態上鎖,相當于失效了當前的中斷;而739行的spin_unlock_irqrestore則是要恢復訪問共享資源前的中斷標志,相當于釋放掉自旋鎖,恢復到之前的中斷狀態.Linux內核的中斷機制中大量使用了自旋鎖機制,可以看出在該函數體內部spin_lock_irqsave和spin_unlock_irqrestore是先后分別被調用的,它們的調用次序是固定的,并且有上鎖的操作則必須有解鎖的操作.

圖4 Linux4.8.8下pcnet32驅動部分代碼段

本文主要在靜態分析方法的基礎上事先通過對設備驅動程序源碼進行分析處理,得到可能的資源操作配對函數信息.圖5顯示了在pcnet32網卡驅動程序的不同函數定義體下相關資源操作的函數.pcnet32_probe1()函數是加載和初始化的網卡驅動程序,1695行的alloc_etherdev是在該函數體中創建網絡設備,禁用網卡之后,網卡程序則在pcnet32_remove()函數體內調用2892行的free_netdev刪除已分配的網絡設備.這兩個函數在對網絡設備資源操作時呈現申請/釋放的對應操作,也即:對內存資源申請之后必須相應地釋放掉,并且調用次序和主調函數都是固定和相對應的.

圖5 Linux4.8.8下pcnet32驅動部分代碼段

3.1.3 獲取配對函數列表

Linux內核開發人員對于內核函數的命名是十分規范的,我們所歸納的這些配對函數的函數名是由規則的語義詞、字符串及下劃線組成的,部分配對函數名稱由一些加上前綴和后綴的字符串拼接組成,每個字符串由下劃線連接,如圖5所示,整個函數名不僅僅有release,還有這個關鍵詞前后的字符串pci和device,因此對于配對函數的識別就需要進行整個字符串語義匹配的綜合判斷.針對預處理設備驅動源程序之后得到的函數列表,對其進行手工分析總結得到一些涉及到內存資源操作,且操作均為對資源的申請/釋放的函數對,表1列出了一些高頻使用的配對函數部分關鍵詞及其相關描述.

對于配對函數的關鍵詞語義集合構建,需要包含全部內核函數資源操作的關鍵詞并歸納出每一對具有相反語義的關鍵詞對.我們給出配對函數的判定條件如下:

1)對于資源進行操作的函數名滿足一定的命名規則;

2)對內存中相同的資源進行操作,且操作的語義是相反的;

3)成對地出現在一個完整的驅動程序執行場景中.

針對以上配對函數的判定條件,提取配對函數需要建立兩個存放不同語義的關鍵詞集,將手工分析得出的關鍵詞分別放入兩個關鍵詞集中.

表1 配對函數關鍵詞描述

圖6給出了提取配對函數的算法.

圖6 提取配對函數算法

根據以上的對配對函數的介紹和判定條件,對配對函數的提取和匹配主要有圖6中所描述的以下幾個關鍵過程:首先創建兩個關鍵詞集分別為內存資源申請關鍵詞集requestSet、內存資源釋放關鍵詞集releaseSet,以及一個配對函數詞集pairSet.針對遍歷預處理設備驅動源程序之后得到的函數原型列表文件,掃描得到配對函數詞集中的關鍵詞記錄,以此來進一步發掘可能需要處理的函數名列表.對于關鍵詞記錄表中每個關鍵字段,將其分別和內存資源申請關鍵詞集 requestSet、內存資源釋放關鍵詞集releaseSet相匹配,以此判斷它是否為資源操作相關函數的關鍵字段.然后,對每個存在配對可能性的資源申請函數func之后,我們遍歷檢查找出與之對應的函數func_nt.如果func_nt是func的配對函數,則它必須首先必須是一個資源釋放函數,并與函數func對相同的內存數據進行操作.接著我們對資源釋放函數func_nt以及資源申請函數func的匹配程度進行計算,兩個函數名配對的關聯性決定了匹配度,計算主要過程如下:

1)初始的匹配度D設為內存資源申請/釋放關鍵詞集在關鍵詞完全匹配的狀態下的匹配度;

2)若關鍵詞所在函數名為單個字符串,直接計算對應的匹配度,匹配失敗則匹配度D為0;

3)若關鍵詞是多組字符串和下劃線構成的函數名,對關鍵詞所在函數名的字段進行分割,若都含有更多相同的子串則匹配度越高,若子串不完全相同則匹配兩個函數名的最長子串,根據相應結果計算不同的匹配度D.

根據每一對資源操作函數func與func_nt,匹配度D超過設置的閾值D,則配對成功,添加到配對函數對當中;匹配度小于設定閾值D的函數,根據最后得到的配對程度報告文件,對匹配程度低的資源操作函數對進行人工檢查驗證,來確認其是否為真正的配對函數.通過多次挖掘并修正結果,優化子串的匹配過程,找出真正對內存資源進行操作的配對函數,可以為后續檢查函數調用關系和路徑工作減少大量不必要的工作量,從而更高效全面地來檢測設備驅動中內存資源操作的潛在違規行為:如果當前的函數是配對函數詞集PairSet里的一個資源申請函數func,搜索pairSet中是否有與其對應的、對相同數據進行操作的資源釋放函數func_nt,如果未找到滿足條件的函數,此時極有可能出現內存資源的違規操作現象.

3.2 配對函數調用上下文場景

3.2.1 調用關系與調用層級

本階段的任務主要是獲取各驅動函數的調用情況、內存資源操作函數的調用關系以及調用層級,建立并維護每個資源操作函數的在各個驅動函數體內部的調用狀態列表以及跨驅動函數調用情況下的調用狀態列表.該階段主要設計的函數調用原型列表及相關信息的數據結構如下:

其中ContextOfInvokingFunction里mContextLevel為當前的調用層級,也就是在源程序里的驅動函數體內或函數間的整個調用關系中,按照操作的次序來給資源申請函數/資源釋放函數編號,并且在每個資源操作函數的狀態列表中記錄當前的條件分支.如圖7(a)的函數調用簡略示意代碼段所示,在整個調用層級模式以及條件語句結構的基礎上構建邏輯次序,a_alloc()～f_alloc()表示資源申請函數,a’_free()～f’_free()表示資源釋放函數,根據調用關系及其對稱性,可以大致歸結出:在每個完整的程序分支中,配對函數的調用必須是成對的,對于某一內存資源,有申請必有釋放;在調用層級上,每個資源操作函數列表及該函數下列表的調用關系是對稱的,因為對于內存資源滿足先申請后釋放的次序,若驅動函數申請資源失敗,必須確保執行到最后可以把該資源申請操作之前的所申請的內存資源按照對稱的次序全部釋放掉,以確保沒有資源操作的漏洞,驅動源程序中的多重分支也是如此.圖7(a)代碼段所對應的整個資源操作函數調用的次序如圖7(b)所示.

圖7 函數層級示例

在與內核進行交互時,設備驅動程序可能會遇到突發的異常情況.為了保證設備驅動代碼的可靠性,必須要提供處理這些突發情況的異常處理代碼分支.因此,大多數設備驅動程序都會在這種情況下有對應的異常處理代碼.多數設備驅動程序基本都是用C語言編寫的,因此無法使用C ++和Java中的一些異常處理或垃圾回收機制.在設備驅動程序中最常用的異常處理機制就是基于goto語句的代碼異常處理機制[15].在該機制中,goto語句用于處理不同狀況下的異常,并且所有異常處理代碼基本都位于每個設備驅動函數體內的末尾位置,放置于每一個獨立的代碼段中.例如圖5中,當1695行的申請以太網設備函數alloc_etherdev()返回異常時,驅動程序將會跳轉到1951行起始的err_release_region代碼段.

在異常處理代碼段中的每個資源釋放函數都應該與該狀態前的正常執行的資源申請函數形成層級性配對,也即必須在異常處理部分逆序釋放當前調用狀態列表中所有已分配內存資源的申請函數.

在異常處理代碼段中的每個資源釋放函數都應該與該狀態前的正常執行的資源申請函數形成層級性配對,也即必須在異常處理部分逆序釋放當前調用狀態列表中所有已分配內存資源的申請函數.

3.2.2 建立執行路徑

本階段的任務是基于每個資源操作函數的調用狀態列表建立完整的配對函數執行路徑.如果函數調用列表中的某個驅動函數體內沒有調用其他驅動函數,就只在該驅動函數體內建立配對函數的執行路徑,如果存在其他驅動函數,則需要跨函數建立配對函數的整個執行路徑.

針對單個驅動函數體內建立配對函數執行路徑的情況,首先要從調用狀態列表取出當前資源申請函數調用起始位置所在的驅動函數,也即其主調函數信息;然后依據該驅動函數體內相應的最近層級配對函數調用狀態列表提取出語義相反的資源釋放函數,綜合二者調用狀態列表中的調用層級(驅動函數體內首個資源申請函數和最后一個資源釋放函數,對應層級為0層)、操作參數,在執行過程中每多加載一個資源申請函數,則對應層級加1,而資源釋放函數則是每多加載一個則層級減1.最后分析完畢之后若形成完全對稱性匹配,就綜合這些配對函數的狀態形成一條資源申請與釋放的完整路徑信息,整個調用路徑記錄對應著驅動源程序中的行號.若遍歷整個函數體內未找到對應層級的資源釋放函數,則形成不完整路徑的報告.

在分析完單個驅動函數體內的執行路徑之后,則需要針對跨驅動函數的情況建立配對函數執行路徑.此時,如圖7(b)所示,會有一個分析調用路徑入口的主函數h,在該驅動主函數體內,每當分析到出現對另外的驅動函數進行調用的情況,此時要從函數調用狀態列表中提取并記錄調用的位置,然后提取被調用驅動函數體中的配對函數列表,載入該列表信息后,再綜合當前的主函數建立配對函數總的執行路徑.

在得到了每個驅動函數體內的配對函數并確立了每個資源操作函數的對應層級、調用信息、相關參數之后,對配對函數集合中的申請資源函數名進行遍歷時,從每個資源申請函數開始作為根節點,子節點和葉節點分別定義為資源申請函數涉及的內存變量、執行路徑終點的資源釋放函數和相關參數.從根節點開始依次往后搜索尋找子節點、葉節點,對于每個子節點,重復進行向后搜索的流程直到抵達葉節點,最終得出每條完整的執行路徑集合及其所對應的資源操作集合.因此每條完整的路徑集合可以看做一棵包含參數信息的以順序執行序列構成的結構化數據流樹,每棵由最外層資源申請函數作為數據流起點的樹中包含了其內部所有以被調資源申請函數為起點的子樹,子樹數量為n.每棵樹的深度為d,d的值為滿足以下條件的最小值:

將真實的執行路徑集合占整個路徑數量的比例λ進行統計,由于實驗的源碼量大,λ的值一般均不超過20%,并且λ越小,子樹數量n越小,相應的平均執行時間越少.因此在各運行路徑上構造數據流樹的平均執行時間都是比較少的,基本上處于平穩增加的狀態,整個數據流樹的構造過程不會造成樹的深度d取值過大的問題.

3.2.3 內存資源操作違規性檢測

上述PFED原型方法主要是建立在對設備驅動源碼進行靜態分析的基礎上去實現的,在提取驅動源程序中的配對函數之后,再針對性的對預處理之后的源程序分析獲取每個資源操作函數的調用上下文場景信息,最后建立多條完整的配對函數執行路徑.在驗證設備驅動內存資源申請釋放的層級匹配過程中,要注意的一點是,同類設備驅動程序大多數情況下的執行邏輯相同,例如網卡設備驅動的整個工作流程基本上遵循這樣的流程:探測、啟動、發送和接受數據包、關閉、注銷.因此對于驅動函數體的整個檢測順序和每個驅動函數調用場景的建立也要遵循具體的運行邏輯.

通過對Linux2.6.20及 4.8.8內核版本下的網卡、聲卡、USB等設備驅動源程序的分析處理,我們在多次修正了子串的匹配過程及調整了匹配閾值T之后,綜合各驅動程序中的提取配對函數結果,PFED分別可提取出共計54和57對由不同前綴或后綴字符、關鍵詞以及下劃線組成的配對函數,然后通過人工檢查驗證,分別確定了49和52對真正的配對函數.

在結合配對函數調用狀態列表之后,最后確立的不完整調用場景報告在整個函數執行場景報告中大約占據約2.5%的比例.如圖8所示的Linux下的USB設備驅動代碼段示例中,存在配對函數在調用層級上不匹配的異常情況:在驅動函數zd_op_start ()中的

332 行、334行、336行處的異常處理代碼中,分別調用了資源釋放函數,這三處釋放函數嚴格按調用層級與前面的資源申請函數zd_chip_enable_rxtx(),zd_chip_switch_radio_on(),zd_chip_enable_int()相對應,若申請資源失敗,則跳轉到異常處理部分把前面調用的資源申請函數按照對稱的次序釋放掉.但是在正常執行路徑上,與zd_op_start()所對應的驅動關閉函數zd_op_stop()中的zd_chip_disable_rxtx(),zd_chip_disable_hwint()這兩處的釋放函數的層級顛倒了,由于先調用了zd_chip_switch_radio_off釋放函數,可能導致 zd_chip_disable_rxtx釋放函數引發內存資源操作不當的問題,進一步造成死鎖狀態.

圖8 Linux4.8.8下via-rhine驅動部分代碼段

4 實驗結果與分析

4.1 實驗方法

1)實驗環境:硬件環境為Intel(R)Core(TM)i7-4710MQ CPU @ 2.50 GHz,8.00 GB內存,500 GB硬盤;軟件環境為Ubuntu 14.04 LTS操作系統;開發和編譯工具為Gedit、GCC4.8,C語言.

2)實驗樣本:本實驗使用Linux內核版本為4.8.8下的六個網卡、聲卡及USB驅動:pcnet32,ens1370,e100,sky2,zd_mac以及 via-rhine.

針對設備驅動內存資源申請與釋放相關操作的檢測問題,我們將本文提出的PFED原型工具在不同種類設備驅動程序上進行了測試比較,實驗展示了在6個不同的測試用例上最終分析得到結果與人工分析得到結果之間的誤差,進行準確性與可靠性評估.其中對于提取配對函數實驗的結果,漏報率(false negative)指標是對比手工分析結果,最終自動提取結果中未出現的配對函數對數占實際配對函數對數的比例;誤報率(false positive)指標是對比兩份配對函數結果報告,自動提取結果中含有手工分析報告未出現的配對函數對數占實際配對函數對數的比例.

4.2 實驗結果及分析

通過在不同類型的設備驅動程序上提取到的配對函數對數與手工分析得到的真實結果進行對比,以及對最后結果的漏報率、誤報率進行統計,來評估本方法的準確性.

針對預處理源程序提取的配對函數結果如表2所示,按照對每個驅動函數體內不去重的方式記錄提取結果.由表2可以看出,由于本文提出的方法是在對源碼的高覆蓋程度下進行分析,并且多次糾正優化了函數名子串匹配過程,通過人工驗證檢測結果,最終結果的漏報率和誤報率都比較低,均不超過15%.

表2 提取配對函數結果

本方法的可靠性通過對不同版本下的驅動源程序的漏洞檢測結果報告和人工驗證真實的設備驅動資源操作漏洞結果進行對比評估,結果如表3所示.

表3 漏洞檢測部分結果

實驗檢測到的跨驅動函數調用配對函數情況共22例,由于驅動程序特有的結構性基礎,在靜態分析過程中涉及到的跨函數調用場景配對檢查情況,我們在此處花費了更多的人工驗證時間.基于我們提取出的全部配對函數列表,以及建立的函數調用場景,根據不同的調用層級和申請釋放層級,形成對應層級的資源操作漏洞檢測結果.表3中給出了部分檢測報告,其中對應層級表示的是該對資源操作函數處于函數體的哪一層.最終總計得到了6處可能出現資源匹配問題的有關漏洞檢測結果,經過人工驗證,發現有1處誤報,1處漏報.因此該方法在滿足對源程序的高覆蓋度情況下,可以有效地檢測出潛在的設備驅動資源操作漏洞.

由于部分設備驅動函數的調用列表有時會不滿足規范的資源操作邏輯流程、驅動函數出現的個別接口函數私有化命名現象、驅動程序設計開發時違背編碼規范等問題,會導致分析結果中出現誤判.一些設備驅動程序中用以獲取當前設備狀態的內核接口函數,比如netif_carrier_ok/netif_carrier_on/netif_carrier_off這組用來判斷網絡通路是否為正常連接狀態的接口函數,網卡驅動會通過它們和內核中的網絡子系統傳遞消息,但是這些接口函數并未涉及到內存資源操作.因此在檢測過程中我們會剔除這些無法應用正常分析流程的特殊實例,在關鍵詞集中建立特殊名單機制并通過迭代檢測結果更新名單以提高整個檢測過程的效率,降低誤判率.

5 結論與展望

本文提出一種基于配對函數調用場景的設備驅動漏洞檢測的研究方法及相關原型PFED,與現有的驅動漏洞檢測方法相比,我們的方法不依賴于編譯后形成的中間語言和真實情境下的硬件設備,在結合了設備驅動工作流程及相關調用函數信息的基礎之后,主要針對提取出的配對函數在執行路徑上的調用場景信息,增加了需要進行分析的信息量,并有效檢測出配對函數在調用層級上不匹配的潛在驅動漏洞.實驗結果表明,PFED提取的配對函數結果更為精確,具有較低的漏報率、誤報率,在檢測設備驅動資源操作漏洞方面具有較高的可靠性,并且進一步提高了源程序的覆蓋度和檢測的準確度.然而,本文的方法也存在許多不足,對于配對函數篩選結果中匹配度低的函數需要人工檢查驗證,今后的研究應考慮設置自動驗證和糾錯反饋機制,將匹配度低的配對函數分類別處理,使配對函數提取的整個過程實現完全自動化.并且如何進一步地結合更多種類的設備驅動結構、將符號執行技術應用于函數調用場景中以提高檢測效率,也將成為未來的研究工作.