論文題目論文出處

AURORA: Statistical Crash Analysis for Automated Root Cause Explanation	USENIX 2020
A priority based path searching method for improving hybrid fuzzing	Computers & Security 2021
SymQEMU:Compilation-based symbolic execution for binaries	NDSS 2021

文章目錄

• AURORA: Statistical Crash Analysis for Automated Root Cause Explanation
• • 論文概要
  • insight
  • 方法
• A priority based path searching method for improving hybrid fuzzing
• • Insight
  • 方法
  • 方法細節
• SymQEMU:Compilation-based symbolic execution for binaries
• • 背景
  • Insight
  • 方法

AURORA: Statistical Crash Analysis for Automated Root Cause Explanation

作者 ：Tim Blazytko, Moritz Schl?gel, Cornelius Aschermann, Ali Abbasi, Joel Frank, Simon W?rner and Thorsten Holz
第一作者單位：Ruhr-Universit?t Bochum, Germany

論文概要

??相比已經有成熟的自動化工具的漏洞挖掘，漏洞分析在目前還很依賴于人工。一方面漏洞挖掘生成的crashes很多都是一個root cause引起的，需要對大批的crashes進行一個分類的大動作；另一方面root cause不好分析，程序的崩潰點和漏洞點往往不在一個地方，需要沿著crash文件的執行路徑去反推漏洞點在哪里，這個很不容易。
??現有的工作需要花費大量的人力去找到root cause。對于上面講的第一個方面，一些工具在對crash去重的時候依賴于ASAN、GDB啊這些工具生成的call stack，它并不是一個root cause分一堆，可能會產生好多堆crash，去重去了個寂寞；也有可能會分錯。
??這篇論文的方法主要是想給人工分析root cause提供便利，不是說完全自動化地找到root cause，它主要是把引起crash的程序行為都記錄下來，借助沒有觸發crash的輸入的程序行為提取出和觸發crash相關的關鍵行為，并且根據某些指標給這些關鍵行為排個序，這些行為能夠幫助分析人員來分析root cause，減輕人工分析的壓力。

insight

??這篇論文圍繞類型混淆類的漏洞對現有的漏洞分析方法的局限性做了討論。

ASAN能夠識別非法內存訪問即使這個程序還沒有崩。但是類型混淆類的漏洞的漏洞點它是沒有內存錯誤的。

反向污點分析比較依賴數據流信息，通過數據流去反推root cause。但是有時候crash和漏洞點之間沒有數據流連接的。

??那么問題就轉化成當沒有直接數據流連接的時候怎么辦。這篇論文認為同一個root cause它可能造成程序在不同的位置崩潰，這個crash沒有直接的數據流連接，那我們就生成更多的crashes，總有一個是有數據流連接的。

方法

??基于上述思想，AFL這類的工具提供有crash mode，把一個crash作為變異的對象生成大量新的crashes，這樣能夠提供更多不同的程序行為，不同的程序行為之間的相似點就可以縮小分析的范圍。在此基礎上還有grammar-based fuzzer，它能夠識別出來強制類型轉換操作。

??總體方法:

給定一個crash，用它作為初始測試用例跑AFL的crash mode。生成的測試用例按照是否使程序崩潰分為兩組。把crash的輸入放到一堆，沒有crash的輸入放到另一堆。

記錄輸入的行為，如被修改的寄存器、記錄被寫訪問的內存地址的最大和最小值等。因為引起crash的值通常是最小值或最大值，因此它只記錄了最小值和最大值，收集堆棧的地址去測試是否有非法指針。把這些值記錄在控制流圖中。

基于上一步，對于觸發crash和沒有觸發crash的輸入各自提取其固有行為。這些固有行為能夠用來預測一個輸入是否crash。崩潰的地點離root cause越近的輸入它會給高的分數，最后按照分數高低它會給出一個列表供人工分析root cause。

人工分析

• 根據第三步得到的控制流圖以及信息，得到一組指令（崩潰的輸入執行，沒崩潰的輸入沒有執行的指令）。
• 生成三種類型的預測：
  • 控制流預測，就是一個基本塊x到基本塊y有幾條路徑。
  • 寄存器以及內存預測。預測寄存器取值的極值。
  • flag預測。記錄標志寄存器的值。
• 這些步驟都是為了計算一個值來預測這個輸入能否crash。然后在每個預測崩潰的關鍵位置設置斷點，來看輸入觸發crash的時序信息，記為execution rank。
• 最后生成一個和崩潰相關的關鍵位置的排序，以便人工分析。

A priority based path searching method for improving hybrid fuzzing

Insight

??這篇論文核心的一個觀點是混合模糊測試中符號執行不應該只是分配解空間小的路徑，而是分配需要它求解并且它容易求解出來的路徑。因為存在一些約束條件符號執行花費大量的資源也不一定就能求解成功。因此這篇論文就提出一種評估輸入的約束條件求解難度的方法。然后提出了一種新的混合模糊測試輸入調度方法。
??這篇論文首先分析了MDPC和DigFuzz的局限性。對于MDPC：
?? 1. 對每條路徑評估fuzzing和concolic execution探索這條路徑的難度花銷很大。
?? 2. 沒有一個合理的指標去評估fuzzing和concolic execution探索某條路徑的難度。
??對于DigFuzz：
??1. 它是從fuzzing的角度去評估它覆蓋一條路徑的難度，但是concolic execution進行約束求解的開銷沒有考慮。
??2. 蒙特卡洛模型需要大量的樣本來使得它的估計有效。
??因此，這篇論文認為concolic execution應該選擇那些容易求解并且重要的路徑去探索。

方法

??這篇論文認為在大多數情況下，一條未覆蓋路徑的約束的求解難度和它的長度有關。然后它通過一系列的實驗得出一個結論：在一般情況下，如果兩個路徑長度相同，那么它們的求解難度也相同。于是可以基于路徑長度評估一條路徑求解的花銷。再結合DigFuzz（他自己提出了一種方法，但本質上和DigFuzz一樣）去做路徑的demand quantifying。最后結合二者計算出一個路徑的分數，用于路徑分配。

方法細節

一些定義

定義了一個樹形結構表示控制流依賴

定義了hard constraint，比起線性約束和非線性約束還存在一些約束對于symbolic execution而言是很難求解的。

未覆蓋路徑的長度

記錄覆蓋每個路徑的輸入的數量。

未覆蓋的分支。

通過實驗得出一些觀察

不同的程序中同一種類的約束條件的分布是近似的

求解同一種類約束條件的時間開銷是一致的。

然后它得出的結論是如果兩個路徑長度相同，那么它們的求解難度也相同。

分數計算方式：

框架：

SymQEMU:Compilation-based symbolic execution for binaries

作者：Sebastian Poeplau，Aur′elien Francillon
出處：NDSS 2021

背景

??二進制層面的符號執行面臨性能和架構依賴性之間的trade-off問題，本文想提出兼顧跨架構性、實現復雜度低、性能高的符號執行方法。以下是對現有的方法的討論：

Angr：運行時把目標程序翻譯成VEX指令，在VEX指令的基礎上進行符號執行。優點：VEX支持的架構它也都支持。

S2E:用QEMU起一個操作系統，然后連接到KLEE。QEMU負責把目標程序從機器碼翻譯成TCG，然后再轉化成LLVM字節碼，然后KLEE在LLVM字節碼的基礎上進行符號執行。

QSYM：使用Pin在運行的時候對x86機器碼進行插樁，插入符號跟蹤，然后進行符號執行，但是它針對X86進行定制化地實現，如果想支持別的架構就很麻煩。

SymCC：源碼層面的一個工具，它就是在編譯階段就把符號執行相關的操作插樁到程序中。

Insight

??首先現有的方法在開發實現的時候要進行一個中間語言的翻譯，如S2E要把機器碼轉化成TCG再轉化成LLVM字節碼給KLEE。第二點，當前的工具都是在測試的時候進行符號的解釋、約束收集、求解等。這篇論文直接hook QEMU的二進制翻譯機制來直接把符號處理編譯進機器碼里面。相當于S2E和SymCC的結合。

方法

設計目標

性能好，能夠支撐真實世界的軟件。

不依賴特定平臺，或者要支持新的平臺很簡單。

方法設計

在目標程序運行時把它轉化成一個中間語言。

在中間語言里進行插樁，插入符號執行相關的操作。

把中間語言再編譯成字節碼用于CPU運行和分析。

總結

以上是生活随笔為你收集整理的论文阅读4.6-4.8的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。