基于懸空指針追蹤的UAF 漏洞檢測方法研究

摘要： 隨著UAF 漏洞的關注度上升，其利用方式更加多樣，對計算機系統造成的威脅愈發嚴重. 因此，本文提出一個輕量級的UAF 漏洞檢測方案. 該方案在LLVM IR 的基礎上收集被測試程序中所有可能的懸空指針；然后，對它們進行精準的數據流分析和控制流分析后，可以排除再次定義的指針，得到所有懸空指針；最后，對懸空指針進行可達性分析和數據流分析即可得到UAF 漏洞的操作序列. 該方案還通過2 種方式減少系統開銷：將過程間分析簡化為過程內分析和結合數據流分析的別名分析算法. 在開源的測試用例和真實程序上測試的實驗結果表明，該方案可以快速、準確地識別出代碼中的UAF 漏洞，并報告危險的操作序列.

關鍵詞： 懸空指針； LLVM； UAF； 漏洞檢測

中圖分類號： TP391. 1 文獻標志碼： A DOI： 10. 19907/j. 0490-6756. 2024. 043001

1 引言

根據NIST 的統計數據［1］顯示，2021 年公布的新增漏洞數量再創新高，達到20 158 個. 如圖1 所示，釋放后重用（Use-After-Free，UAF）漏洞自2015 年開始逐漸增多. 這主要是由于開發人員的安全意識提高和眾多堆棧保護機制的廣泛應用，使得溢出漏洞發現和利用的難度加大，研究人員逐漸轉向發現和利用堆運行機制漏洞. Yan 等［2］的研究表明，NVD 數據庫中有80. 14% 的UAF 漏洞被評為高危或嚴重等級. 相比之下，大約只有50%的堆緩沖區溢出漏洞被視為高危等級的漏洞［3］.UAF 漏洞作為堆內存分配機制的基本漏洞，可以通過它對計算機系統進行更復雜且危害性更大的攻擊. 如HeapFengShui［4］等，可能導致拒絕服務，信息泄漏，甚至是任意代碼執行攻擊.

UAF 漏洞由2 個條件組成：（1） 產生懸空指針；（2） 使用懸空指針. 其中懸空指針是指指向的內存對象被釋放后沒有被正確處理的指針. 因此若要檢測UAF 漏洞或緩解UAF 漏洞帶來的危害，檢測懸空指針就顯得尤為重要.

目前針對懸空指針的檢測也有一些成熟的技術. DangSan［5］以LLVM［6］編譯框架插件的形式工作，通過指針追蹤器和內存對象追蹤器分別追蹤內存對象指針和內存對象，并使用映射器將其關聯. 最后在內存對象被釋放時得到相應的懸空指針，并使其失效，從而達到防止UAF 漏洞的目的.不過由于指針追蹤的復雜性導致存在誤報，并且指針追蹤器追蹤所有指針導致開銷較大. 為了解決開銷問題，HeapExpo［7］在DangSan 的基礎上進行改進，對每個函數的局部指針和指針參數進行活躍分析，配合LLVM 的mem2reg 優化，從而減少需要跟蹤的指針變量數量，減小了系統開銷. DangNULL［8］和FreeSentry［9］也是追蹤指針傳播，并記錄指針與對象之間的關系. 不過二者用于記錄的數據結構不同，前者采用紅黑樹進行元數據存儲，其中每個節點對應1 個內存對象和所有指向該內存對象的指針，而后者使用2 個查找表作為其元數據存儲：一個表記錄從指針到其引用的內存對象的所有映射，另一個表記錄從內存對象到引用它的指針的所有映射. 在跟蹤指針傳播方面，Dang?Null 只跟蹤數據段和堆中的指針，不跟蹤堆棧或寄存器中的指針. 而FreeSentry 跟蹤堆棧上的指針，但不跟蹤寄存器中的指針. 因此，這會導致UAF漏洞漏報.

此外，也有一些專門針對UAF 漏洞的自動檢測技術，根據是否需要運行程序分為2 類：靜態檢測和動態檢測. 靜態檢測，如CBMC［10］、Coccinelle［11］、Clang 靜態分析器［12］和TscanCode［13］等，通過在不執行程序的情況下分析源代碼或機器代碼來發現程序中潛在的UAF 漏洞；而動態檢測，如Valgrind［14］和Dr. Memory［15］等，在程序執行期間報告潛在的UAF 漏洞.

在眾多靜態檢測技術中，UAFChecker［16］通過構建有限狀態機來檢測程序中的所有指針或其別名在釋放其內存對象后是否再次被使用，作為可能的UAF 漏洞. 然后使用符號執行檢查可能的UAF 漏洞的路徑約束的可滿足性來減少誤報率.但是由于約束求解的局限性以及使用函數內聯技術和函數摘要技術進行過程間分析帶來的巨大開銷，導致它僅適用于較小的程序. CRed［2］首先對C程序進行基于需求驅動的指針分析獲取可能的UAF 漏洞，然后通過函數調用上下文敏感縮減技術和路徑敏感縮減技術逐步減少誤報率. 為了減少分析時間，CRed 通過設置函數調用上下文的深度來減少需要分析的程序路徑的數量. 因此CRed會遺漏一些UAF 漏洞. 此外，由于CRed 對數組訪問別名的建模不完善，并且缺乏對鏈接列表的處理，即使沒有減少函數調用上下文深度，它也可能會遺漏真正的UAF 漏洞.

與上述對指針進行詳細分析不同，CBMC 是將模型檢查［17］與可滿足性求解相結合的有界模型檢查工具. CBMC 首先將每個循環展開到固定邊界，然后再將程序轉換為使用UAF 斷言注釋的程序. 然后，它將所有可能的程序路徑視為約束，并使用SMT 求解器對其進行求解，以確定程序是否包含UAF 約束違規. 盡管精度很高，但由于約束求解的局限性，CBMC 只能擴展到小型程序.

Coccinelle 和TscanCode 都是采用給定的模式來分析和驗證C 程序中的漏洞. 因此二者具有很高的擴展性，但給定模式也降低了漏洞檢測的精度. 此外，由于指針分析不佳和模式匹配的性質，前者容易產生大量誤報；后者由于缺乏指針分析，所以在真實程序中難以檢測UAF 漏洞. Clang 靜態分析器通過在軟件編譯過程中執行控制流分析、路徑敏感分析和過程間分析進行漏洞檢測. 為了平衡有效性和可擴展性，它通過函數內聯技術執行有限的過程間分析，并且只進行簡單的指針分析和保守的循環分析. 因此，在減少誤報率的同時，也會漏報一些程序間和程序內的UAF 漏洞.

除以上主要針對源代碼的UAF 檢測技術，對于應用場景更多的二進制程序，也有一些UAF 檢測技術. 由于二進制程序相比源碼缺失更多的信息，所以一般都是在二進制程序的基礎上提取出抽象信息用于指導檢測. 如GUEB［18］先構建出抽象內存模型作為其中間表示；然后通過值分析和指針別名分析來跟蹤堆的操作和指針傳播；最后為檢測到的每個UAF 漏洞提取1 個子圖，以描述指針的創建、釋放和使用位置. GUEB 可以在沒有源代碼的情況下檢測UAF 漏洞，并且比嚴重依賴于測試用例的動態檢測器提供更好的覆蓋率. 然而，由于反匯編技術的誤差和不完善的指針分析，GUEB 的檢測結果既不精確也不可靠. 此外，GUEB 在分析真正的大型程序時存在一定難度，因為它使用函數內聯技術進行過程間分析，導致多次調用的函數被重復處理［19］. 而UAFDetector［20］提出釋放后使用特征模型為檢測提供指導，再將目標程序的二進制代碼轉換為中間表示并構建控制流圖，最后執行指針跟蹤以識別UAF 漏洞. 其方案與前者類似，它使用函數摘要技術而不是函數內聯技術進行過程間分析，實現了更好的可擴展性，并減少了不必要的分析開銷.

由于部分靜態分析技術的局限性導致靜態檢測存在一定的誤報率，所以部分研究采用動態檢測. Mudflap［21］在C/C++程序編譯時添加內存檢查. Mudflap 在指針的使用位置處靜態插入合法性驗證斷言. 斷言取決于指針是否訪問有效內存，這由Mudflap 維護的有效內存對象列表決定. 實際環境中，對于復雜的C/C++ 程序，Mudflap 會出現較高的誤報率. UAFL［3］利用SVF［22］對中間語言進行過程間分析，依次尋找觸發UAF 漏洞的特定序列的3 個結點：內存申請、內存釋放和內存使用，給出可能存在的UAF 漏洞，然后利用模糊測試技術驗證UAF 漏洞是否存在. DoubleTake［23］對共享庫函數進行修改，使得每個被釋放的內存對象的前128 字節都被填充指定數據，下一次申請內存對象時通過檢查其中的值是否為指定數據來判斷是否存在UAF 漏洞，并立即觸發重新執行以識別此錯誤的原因. 由于它的判斷依據是內存對象中的指定數據是否被修改，所以對于通過UAF 漏洞泄露信息的漏洞無法檢測.

Valgrind 使用反匯編技術首先將機器代碼翻譯成中間表達（Intermediate Representation，IR）形式，再在關鍵位置插入額外的IR 以啟用內存檢查，最后將這些IR 翻譯回機器代碼. 最后在運行時，插入的代碼就可以實時檢測軟件是否有UAF 漏洞觸發. Dr. Memory 與Valgrind 的不同之處在于Dr. Memory 是基于DynamoRIO［24］執行內存檢查優化. DynamoRIO 復制每條指令并且對每條指令都添加相應的注釋，以解釋這條指令的效果. 二者相同之處在于都將影子內存拆分成類似的多級結構，即多級影子映射，以減少內存開銷并加速查詢. Valgrind 和Dr. Memory 的缺點就是由于增加了檢測代碼，導致新的程序對系統開銷增大很多.

簡而言之，動態分析一般先將程序轉換成IR或者直接在二進制文件上進行插樁，然后在程序運行時檢測是否存在UAF 漏洞. 這種方式雖然具有較低的誤報率，但也存在低覆蓋率和高性能開銷問題.

本文的主要貢獻如下：（1） 基于導致UAF 漏洞的2 個條件，本文提出了輕量級的UAF 漏洞靜態檢測方案；（2） 采用調用圖的逆拓撲序列的方式遍歷并處理程序，將過程間分析簡化為過程內分析，減小了系統開銷；（3） 結合基于指令間關系的別名分析和Andersen 別名分析算法的別名分析快速且準確地得到所有懸空指針；（4） 將設計的檢測方案實現并與其他靜態分析工具進行比較，證明了該方案的有效性，且在UAF 漏洞檢測方面優于它們.

2 LLVM

LLVM（Low Level Virtual Machine）是用途廣泛的編譯器基礎架構. 它將編譯器的功能進行模塊化劃分與封裝，使得用戶可以根據自身需求定制編譯器. 如圖2 所示，其主要分為3 部分：編譯器前端、優化器、編譯器后端. 其前端對程序源代碼依次進行詞法分析，語法分析和語義分析，最后生成IR. 優化器使用Pass 對IR 進行優化，既可以優化代碼也可以進行靜態分析. 編譯器后端則根據優化后的IR 生成在目標機器上運行的機器碼，即目標程序.

IR 是屬于低級語言，有如下特點：采用靜態單一賦值（Static Single Assignment，SSA），即每個值只有1 個定義它的賦值操作；代碼被組織為三地址指令（Three-Address Instructions）；寄存器的數量不受限制.

模塊是LLVM IR 的頂層數據結構，包含目標機器信息、函數的聲明定義、符號表和全局變量.函數包含函數的返回類型、函數名、參數類型和函數體. 其中，函數體由一系列基本塊構成，基本塊由一系列各種指令構成，如訪問內存指令、操作內存指令、類型轉換指令、算術運算指令及跳轉指令等，特殊的是最后1 條指令一般都是終止指令. 常見指令及其作用如表1 所示. 其中，getelementptr指令常用于獲取聚合數據結構的子元素的地址，如結構體成員變量的地址.

優化器的功能由1 個或者多個Pass 實現，以LLVM IR 作為輸入輸出. 多個Pass 可以協同工作，并且Pass 支持用戶自定義. 為了實現不同級別的優化和分析，需要通過繼承Pass 類的子類MoudlePass、FunctionPass 和BasicBlockPass 實現. 它們分別代表模塊級、函數級和基本塊級. 示例如圖3，該自定義Pass 使用LLVM 的CallGraph?WrapperPass 打印出程序中所有函數的函數名.

LLVM 中的Value 類和User 類是2 個非常重要的基類，其中繼承于Value 的子類表示它的結果可以在其他地方使用，而繼承于User 的子類表示它會使用1 個或多個Value 對象. LLVM 在SSA 的基礎上根據Value 與User 之間的關系得出use-def鏈和def-use 鏈. use-def 鏈是指被某個User 使用的Value 列表，def-use 鏈是使用某個Value 的User 列表. 它們極大地提升了LLVM 的數據流分析能力.

3 UAF 漏洞檢測方案

本節首先概述整個UAF 漏洞檢測流程，然后再詳細描述UAF 漏洞檢測方案的具體細節.

3. 1 整體設計

UAF 漏洞檢測流程圖如圖4 所示. 通過Clang編譯器編譯源代碼可獲得LLVM IR，但微軟提供的開源工具llvm-mctoll［25］實現將常見架構的二進制程序轉換成LLVM IR，可擴大本方案的適用范圍.

UAF漏洞靜態分析流程如下：（ 1） 通過Clang編譯器或者 llvm-mctoll工具獲取 LLVM IR；（ 2）進行調用圖分析，獲得程序的調用圖的逆拓撲序列；（ 3） 進行控制流分析和數據流分析，獲得被釋放內存對象的指針；（ 4） 使用別名分析，收集所有懸空指針；（ 5） 進行控制流分析，過濾不存在UAF漏洞的懸空指針；（ 6） 利用函數的支配樹細化UAF漏洞操作序列；（ 7） 以操作序列的形式報告UAF 漏洞.

通過數據流分析追蹤懸空指針的傳播，UAF漏洞檢測報告的查全率取決于數據流分析的精確性，是否可以查出所有懸空指針及其別名的傳播.UAF 漏洞誤報是將不存在UAF 漏洞的程序視為存在UAF 漏洞的程序. 由于數據流分析可以精確地獲得懸空指針及其使用指令，所以根據產生UAF 漏洞的2 個條件可知，誤報主要是在分析懸空指針能否被使用的階段產生的，即可達性分析.所以UAF 漏洞檢測報告的查準率受到控制流分析的影響.

3. 2 基于靜態分析的UAF 漏洞檢測方案

UAF 漏洞檢測分為2 部分：檢測程序中可能存在的懸空指針；懸空指針是否被使用.

根據懸空指針的定義可知，若要檢測程序中存在的懸空指針，必須先獲得懸空指針可能產生的位置，即內存釋放函數的調用位置，還需要確保在內存對象被釋放后，相關指針沒有再次被定義.本文中，內存釋放函數分為庫函數和對庫函數封裝的用戶自定義函數2 類，其參數列表中都一定存在被釋放內存對象的指針. 具體檢測方法如算法1所示.

算法1 首先讀取配置文件獲取被測試程序中可能存在的常見內存釋放函數的函數名，如free等，和代表內存對象的指針參數序號. 同時使用LLVM 提供的Pass 構建被測試程序的調用圖，再通過深度優先遍歷調用圖可以得到所有用戶自定義函數的逆拓撲排序. 根據逆拓撲序列開始依次分析每個用戶自定義函數時，如果發現用戶自定義函數中存在內存釋放函數調用，需要對該用戶自定義函數進行深入分析.

分析過程從對內存釋放函數調用指令的處理開始，首先根據參數序號取出被釋放內存對象的指針，然后通過別名分析獲取其別名，得到可能的懸空指針集合. 該別名分析算法在worklist 算法的基礎上結合了基于指令關系的別名分析和Andersen算法［26］.

其中基于指令關系的別名分析主要側重于分析指針變量之間通過賦值運算符進行的賦值操作. 其中，將IR 中的store 指令視為變量的定義操作. load 指令視為使用操作. 基于指令關系的別名分析首先根據內存對象指針變量確定對應的寄存器，然后收集與該寄存器相關的load 和store 指令并對其進行處理. 如圖5 所示，對于函數func1，根據內存釋放函數free 得到被釋放內存對象指針a，遍歷func1 的指令發現在釋放內存之前指針a 賦值給指針b，在IR 中主要表現形式為先使用load 指令獲取指針a，然后使用store 指令將其存儲到指針b中，所以追蹤變量a 的賦值操作時需要獲取load 和store 指令. 函數func2 同理，不過由于已知的內存對象指針是被賦值，所以只需要獲取相關的store指令即可.

除了上述直接利用賦值操作符進行指針復制外，還有利用函數進行指針復制的特殊情況. 上述直接利用數據流分析進行獲取別名的方式對此并不適用，因此考慮使用Andersen 算法. 該算法只是收集與利用上述數據流分析得到的候選懸空指針集合相關的call 指令涉及的指針，然后利用Andersen算法計算其與已知的被釋放內存對象指針是否存在別名關系. 如果存在，則將其視為別名，反之，則舍棄.

通過上述方法獲得程序中所有可能的懸空指針之后，查找其使用位置前，還需要進行驗證，確保其屬于懸空指針，即沒有再次被定義. 本文根據可能的懸空指針是否是全局變量選擇執行不同的檢測方案.

考慮循環結構的影響，對于局部變量類型的候選懸空指針，本文在GetNotRedefined 函數中通過前向分析來確定在某個內存釋放函數之后，哪些指針仍然保持活性. 具體來說，算法首先為函數中的每個指令設置一個in 和out 映射，分別表示函數中的指令執行前后是否可以到達相關的store 指令，然后通過遍歷每個基本塊并按照順序遍歷基本塊中的指令（主要是store，call 和終止指令這3類）來對所有指令進行前向分析. 對于每個指令，代碼檢查其入口和出口，并在此基礎上更新in 和out 映射. 具體而言，當檢測到指令I 的in 與out 映射不同時，算法檢查該指令是否為定義指針變量AI 的store 指令. 如果不是，代碼將修改對應的out映射，以將所有能夠到達I 的指令設置為活性. 接下來，算法按照基本塊終止指令的類型（分支、轉換、間接分支、返回或不可達）更新in 和out 映射.最后，算法根據in 和out 映射中的結果確定哪些store 指令在某個內存釋放函數之后定義了指針.

為了減少過程間分析帶來的性能開銷，本文通過從內存釋放函數調用處開始順序遍歷指令的方式處理全局指針變量，嘗試得到與其相關的store 指令. 如果存在該store 指令，則在檢測懸空指針的使用時，還需要對懸空指針再定義與懸空指針使用之間進行可達性分析. 如果store 指令在load 指令之前執行，則說明該指針在利用之前已經被再次定義，故放棄對該指針的后續處理.

通過上述步驟，最終可以得到程序中的所有的懸空指針及其產生的位置，其中局部懸空指針以alloca 指令形式存儲. 特殊的是，由于僅使用 alloca指令表示局部聚合數據的成員可能導致很高的誤報率，所以為了精準定位聚合數據中的懸空指針，還需要記錄對應的getelementptr 指令的偏移下標.

獲取程序中所有懸空指針后，通過LLVM 的def-use 鏈逐個獲取每個懸空指針的使用者. 如果使用者是訪問內存指令或操作內存指令，且內存釋放函數調用指令與該指令存在通路，則視為存在UAF 漏洞. 需要注意的是，對于局部聚合數據中的懸空指針，通過alloca 指令的def-use 鏈獲取它的使用者之后，還需要確定每個使用者是否是getelementptr指令，如果是該類型指令，還要檢查getelementptr指令的偏移下標是否與收集懸空指針階段保存的偏移下標一致. 只有偏移下標一致，才表明是聚合數據中的懸空指針被使用.

通過上述方法可以檢測出程序中是否存在UAF 漏洞，并以lt;內存釋放位置，內存使用位置gt;映射的形式表示UAF 漏洞. 為了保證內存釋放函數調用指令不會被忽略，還需要實時更新內存釋放函數信息. 更新機制首先會檢查當前集合中的懸空指針是否會導致UAF 漏洞，即是否有對應的lt; 內存釋放位置，內存使用位置gt; 映射. 如果存在，則將對應的lt;內存釋放位置，內存使用位置gt;映射存放到集合中；如果不存在，則對該懸空指針進行數據流分析，檢查其是否屬于當前函數的參數，或存在別名關系. 如果該懸空指針屬于當前函數的參數或存在別名關系，則將當前函數視為用戶自定義的內存釋放函數，并更新內存釋放函數信息.

在獲取程序中所有的UAF 漏洞之后，為了后續更好地分析UAF 漏洞，需要根據lt;內存釋放位置，內存使用位置gt;映射獲取對應的UAF 操作序列. 具體來說，首先對集合中的每個映射進行分析：獲取內存釋放位置所在函數的支配樹，然后獲取內存釋放位置和內存使用位置2 個結點的公共祖先結點，然后從下向上遍歷支配樹，得到從內存釋放位置到內存使用位置必經的所有基本塊，即UAF 漏洞操作序列. 最后，以操作序列的形式報告UAF 漏洞.

4 實驗結果與分析

本文實驗均在Ubuntu 20. 04 64 bit 上進行，處理器為AMD 銳龍5 4600 G，內存分配4 GB. 本文代碼基于C++編寫.

4. 1 實驗對象

為了評估該方案的有效性，本文使用了軟件保障參考數據庫公開的測試樣本集Juliet C/C++ 1. 3［27］對檢測方案進行驗證. 該測試用例集由一組具有已知漏洞的合成C 程序，且涵蓋了軟件中常見的118 種漏洞. 這些程序可以用于測試靜態分析器在各種系統環境下的有效性. 本文僅利用與UAF 漏洞（CWE-416）相關的C 語言測試用例子集，它的測試用例提供了數據結構的不同變體以及不同的控制流和數據流模式中的漏洞示例. 每個測試文件都包含1 個有漏洞的函數和相應的無漏洞函數. 將每個測試用例都分成對應的有漏洞測試用例和無漏洞測試用例，構成了本文使用的包含276 個測試用例的集合. 其中包含138個存在UAF 漏洞的測試樣例和138 個不存在UAF 漏洞的測試樣例. 為了說明該方案在真實環境中的有效性，本文還利用了數個公開漏洞進行驗證，其基本信息如表2 所示.

4. 2 有效性驗證

4. 2. 1 開源測試用例集驗證

將本文提出的UAF 漏洞檢測方案與CBMC、TscanCode、Coccinelle和Clang 靜態分析器這4 個目前主流的靜態分析器進行比較. 實驗結果如表3 所示.

本文方案相比于其他4 個主流的靜態分析器效果更好. 其中，138 個存在UAF 漏洞的樣本都成功地被本文方案檢測出來，并且沒有錯誤地認為138 個正常樣本中存在UAF 漏洞. 其余4 個主流的靜態分析器雖然也沒有產生誤報，但是檢測出來的UAF 漏洞數量都沒有達到全部漏洞的50%，甚至更少. 圖6 直觀地展示了本文方案與其他靜態分析器的有效性分析.

通過開源測試用例集的驗證，說明本文方案對于常見的UAF 漏洞形式都能夠精確且迅速的檢測出來.

4. 2. 2 公開漏洞驗證

公開漏洞驗證結果如表4所示. 對于這5 個真實應用程序，本文提出的方案表現良好，都成功地將其中的UAF 漏洞檢測出來. 對于結構較簡單的bzip2recover 程序甚至做到了零誤報率. 但是對于復雜的程序，為了提高檢測效率，本方案采用了較簡單且保守的控制流分析，因此會導致檢測結果出現一定的誤報率. 由于靜態分析技術的局限性仍然存在一定的誤報率.Clang 靜態分析器只是成功地檢測出了gifsicle 程序中的UAF 漏洞，同時伴隨著誤報. 這主要是由于其對于結構體內部指針的分析具有一定缺陷.由于TscanCode 和Coccinelle 通過模式匹配的方式進行檢測，所以對于結構復雜多變的真實程序，它們表現得也不盡人意，只是檢測出readelf 程序中的UAF 漏洞，并且后者伴隨著大量誤報.

4. 3 性能分析

為了比較5 個檢測工具之間的性能優劣，本文統計了5 種檢測工具對6 個實驗對象進行檢測時的消耗時長，具體數據如表5 所示. 根據圖7 的直觀展示可知，本文提出的方案檢測耗時并不比主流的靜態分析器耗時更多，甚至大多數情況下能夠更快地給出檢測結果. 對于結構越簡單的程序，本文提出的方案表現得越好. 此外，由于CBMC利用約束求解器進行漏洞檢測，導致其所消耗的時間通常是最多的，甚至是本方案所需時間的數十倍以上.

5 結論

因為由懸空指針引起的UAF 漏洞對計算機系統的危害性越來越嚴重，所以本文提出了輕量級的UAF 漏洞檢測方案. 該方案使用調用圖的逆拓撲序列遍歷函數，不斷更新內存釋放函數信息，從而避免過程間分析帶來的系統性能消耗. 此外，該方案還通過結合基于指令關系的別名分析和Andersen別名分析算法，使得別名分析在精確性和性能之間取得平衡. 最后該方案還利用基本塊之間的支配關系豐富每個UAF 漏洞操作序列，使得UAF 漏洞報告更詳細，為后續研究帶來便利. 通過LLVM Pass 實現該方案后，本文從開源測試用例和真實程序2 個角度驗證了該方案的可行性和高效性.

實驗結果表明，方案能夠有效地發現UAF 漏洞. 對于測試樣本集Juliet 中的276 個測試用例，本文提出的工具與其他4 種主流工具相比實現了零漏報率和零誤報率，初步證明了該方案的可行性.此外，本文還用數個公開漏洞進行測試，都成功地檢測出其中的UAF 漏洞. 通過比較不同工具檢測不同程序的消耗時長可以說明，該方案對于小型程序中的UAF 漏洞檢測具有較大優勢. 并且對于結構復雜的程序，也能展示出不錯的效果. 不過，由于可達性分析和數據流分析的難度隨著程序規模的不斷變大而增加，所以對于較復雜的程序，依舊存在一定的誤報率.

目前，該方案也存在一些不足之處. 對于異步程序，由于其控制流圖和調用圖需要考慮回調函數和事件循環，且有可能導致多線程執行，因此通過靜態分析檢測其中的UAF 漏洞可能存在較大的誤報率和漏報率. 此外，本方案雖然可以通過采用llvm-mctoll 工具將二進制程序轉化為LLVM IR，擴大了本方案的適用范圍，但是該工具并不能支持所有架構的二進制程序，且轉換后可能導致程序結構更加復雜.

參考文獻：

［1］ Booth H， Rike D， Witte G A. The national vulnerabilitydatabase（ NVD）： Overview［ EB/OL］.［2023-02-05］. https：//csrc. nist. gov/pubs/itlb/2013/12/thenational-vulnerability-database-nvd-overview/fi-nal.

［2］ Yan H， Sui Y， Chen S， et al. Spatio-temporal contextreduction： A pointer-analysis-based static approachfor detecting use-after-free vulnerabilities［ C］//Proceedings of the 2018 IEEE/ACM 40th InternationalConference on Software Engineering（ ICSE）.New York： IEEE， 2018： 327.

［3］ Wang H， Xie X， Li Y， et al. Typestate-guidedfuzzer for discovering use-after-free vulnerabilities［ C］//Proceedings of the 2020 IEEE/ACM 42nd InternationalConference on Software Engineering（ ICSE）.New York： IEEE， 2020： 999.

［4］ Sotirov A. Heap feng shui in JavaScript［ R］. Amsterdam：Black Hat Europe， 2007： 11.

［5］ Van Der Kouwe E， Nigade V， Giuffrida C. Dangsan：Scalable use-after-free detection ［C］//Proceedingsof the Twelfth European Conference on Com ?puter Systems. New York： Association for Comput?ing Machinery， 2017： 405.

［6］ Lattner C， Adve V. LLVM： A compilation frameworkfor lifelong program analysis amp; transformation［C］//Proceedings of the International Symposiumon Code Generation and Optimization. SanJose： IEEE， 2004： 75.

［7］ Shen Z， Dolan-Gavitt B. Heapexpo： Pinpointing promotedpointers to prevent use-after-free vulnerabilities［ C］//Proceedings of the Annual Computer SecurityApplications Conference. New York： Associationfor Computing Machinery， 2020： 454.

［8］ Lee B， Song C， Jang Y， et al. Preventing use-afterfreewith dangling pointers 1ification ［C］// Proceedingsof the 2015 International Conference onCloud and Autonomic Computing. San Diego： TheInternet Society， 2015.

［9］ Younan Y. FreeSentry： protecting against use-afterfreevulnerabilities due to dangling Pointers ［C］//Proceedings of the 2015 International Conference onCloud and Autonomic Computing. San Diego： TheInternet Society， 2015.

［10］ Kroening D， Tautschnig M. CBMC-C boundedmodel checker： （Competition contribution） ［C］//Proceedings of the 20th International ConferenceTools and Algorithms for the Construction andAnalysis of Systems. Berlin： Springer Berlin Heidelberg，2014： 389.

［11］ Olesen M C， Hansen R R， Lawall J L， et al. Coccinelle：Tool support for automated CERT C securecoding standard certification ［J］. ScI Comput Program，2014， 91： 141.

［12］ Clang. Clang static analyzer ［DB/OL］. ［2023-03-23］. http：//clang-analyzer. llvm. org/.

［13］ Tencent. TscanCode ［DB/OL］. ［2023-03-23］.https：//github. com/Tencent/TscanCode/.

［14］ Nethercote N， Seward J. Valgrind： A framework forheavyweight dynamic binary instrumentation ［J］.ACM Sigplan Notices， 2007， 42： 89.

［15］ Bruening D， Zhao Q. Practical memory checkingwith Dr. Memory ［C］//International Symposium onCode Generation and Optimization （CGO 2011）.New York： IEEE， 2011： 213.

［16］ Ye J， Zhang C， Han X. POSTER： UAFChecker：Scalable static detection of use-after-free vulnerabilities［C］//Proceedings of the 2014 ACM SIGSACConference on Computer and Communications Security.New York： Association for Computing Machinery，2014： 1529.

［17］ Biere A， Cimatti A， Clarke E M， et al. Boundedmodel checking ［J］. Handbook of Satisfiability，2009， 185： 457.

［18］ Feist J， Mounier L， Potet M L. Statically detectinguse after free on binary code ［J］. Journal of ComputerVirology and Hacking Techniques， 2014，10： 211.

［19］ Gui B， Song W， Xiong H， et al. Automated useafter-free detection and exploit mitigation： how farhave we gone ［J］. IEEE T Software Eng，2021， 48：4569.

［20］ Zhu K， Lu Y， Huang H. Scalable static detection ofuse-after-free vulnerabilities in binary code ［J］. IEEEAccess， 2020， 8： 78713.

［21］ Eigler F C. Mudflap： Pointer use checking for C/C++ ［C］//Proceedings of the 2003 GCC Summit.［S. l. ：s. n.］，2003： 57.

［22］ Sui Y， Xue J. SVF： Interprocedural static valueflowanalysis in LLVM ［C］//Proceedings of the25th international conference on compiler construction.New York： Association for Computing Machinery，2016： 265.

［23］ Liu T， Curtsinger C， Berger E D. Doubletake： Fastand precise error detection via evidence-based dynamicanalysis ［C］// Proceedings of the 38th InternationalConference on Software Engineering. NewYork： Association for Computing Machinery，2016： 911.

［24］ Bruening D. Efficient， transparent， and comprehensiveruntime code manipulation ［D］. Cambridge，Boston， MA： Massachusetts Institute of Technology，2004.

［25］ Yadavalli S B， Smith A. Raising binaries to LLVMIR with MCTOLL（ WIP paper）［ C］// Proceedingsof the 20th ACM SIGPLAN/SIGBED InternationalConference on Languages. New York： Associationfor Computing Machinery， 2019： 213.

［26］ Andersen L. Program analysis and specialization forthe C programming language［ D］. Copenhagen： Universityof Copenhagen， 1994.

［27］ NIST. Juliet test suite 1. 3. test suites ［DB/OL］.（2017-10-01）［2023-03-23］. https：//samate. nist.gov/SRD/testsuite. php/.

（責任編輯： 伍少梅）

基金項目： 國家重點研發計劃項目（2021YGB3101800）