Fuzzing論文_Fw-fuzz

• • 論文概要
  • 論文背景
  • 動機
  • 挑戰
  • 模型設計
  • • • 框架
      • workflow
  • 具體實現
  • • • 1. 跨架構插樁
      • 2. 錯誤檢測
      • 3. 優化插樁算法
      • 4.測試用例生成
  • 實驗
  • 部分原文摘抄
  • 其他相關論文

論文題目Fw-fuzz: A code coverage-guided fuzzing framework for network protocols on firmware

工具名稱	Fw-fuzz
論文來源	CONCURRENCY AND COMPUTATION-PRACTICE & EXPERIENCE 2020
一作	Zicong Gao(Cyberspace Security Department, State Key Laboratory of Mathematical Engineering and Advanced Computing, Zhengzhou, China)
文章鏈接	https://doi.org/10.1002/cpe.5756

論文概要

這篇論文針提出一種覆蓋率導向的固件協議fuzzing方法。在物理設備上進行動態插樁。能夠獲取MIPS, ARM，PPC等架構固件程序的代碼覆蓋率。我覺得這個論文的亮點在于它的host-device的架構，并且實現跨平臺獲取代碼覆蓋率，這個框架是很方便的。但是，對于feedback引導變異這一塊其實只是引導種子選擇，它的remove機制也沒有影響變異策略的意思，感覺這一塊有待改進。目前沒有找到開源代碼。

論文背景

IOT設備的固件將一系列的軟件集成在設備上以實現硬件與軟件之間的交互，然而這些固件上的程序通常存在很多漏洞，需要我們對這些漏洞進行檢測。

動機

黑盒的fuzzing工具無法知道程序的內部結構，因此會浪費大量的資源在生成無用的測試用例上；
AFL等現有的灰盒fuzzing沒有辦法通過解空間小的路徑，且插樁不支持固件程序運行的環境；
白盒fuzzing需要源代碼，但是固件通常不是開源的。

挑戰

對嵌入式系統固件的協議進行fuzzing有以下挑戰：錯誤檢測、性能以及拓展性、插樁。
一些研究對固件進行全仿真或者部分仿真，但是仿真環境下執行和實際執行的數據流經常是不相同的，而且仿真所支持的架構受Qemu的限制。
當前的工具Peach,Boofuzz等都是黑盒fuzzing,需要用戶定義輸入生成的規則。DELTA，SecFuzz和Ruiiter則側重于通過神經網絡學習來生成輸入而不是依靠feedback。

本文中列出的挑戰：

測試用例生成效率低。對于協議的每個字段都進行測試效率很低。因此測試用例生成不僅僅要考慮協議的格式也要根據運行時的反饋信息動態的調整。

跨架構插樁。嵌入式系統的架構多種多樣，在無源代碼的情況下進行跨架構插樁很重要。

錯誤檢測。固件很少有保護措施，導致很難直接觀察到crash，因此需要捕獲fuzzing期間的異常。

模型設計

框架

模型框架如上圖，有4部分組成。控制模塊用于調度其他模塊，在host和設備之間傳遞控制指令。插樁模塊在物理設備上進行插樁，反饋程序運行狀態。傳輸模塊用于給目標程序發送和接收網絡數據包。測試用例生成模塊不斷地生成新的測試用例。并且整個框架分為兩個部分host和device。

workflow

用戶定義協議的模板文件作為初始輸入。

控制模塊吧控制指令發送給agent來提醒插樁執行器（instrumentation actuator）連接目標程序。

控制模塊開啟插樁調試器（instrumentation debugger）連接插樁執行器（instrumentation actuator）。

傳輸模塊發送數據包給目標程序，一輪fuzzing開始。

fuzzing過程中不斷反饋運行信息給host。

插樁模塊不斷地捕獲crash和異常。

測試用例生成模塊根據反饋的信息變異測試用例。

進入下一輪的fuzzing，重復5-7。

具體實現

1. 跨架構插樁

使用GDB和Capstone實現跨架構。GDB可以在server模式下遠程對不同架構下的程序進行調試。Capstone可以對二進制進行逆向分析。它也支持多架構。
首先要在目標設備上編譯GDB server，然后建立GDB Server和GDB debugger之間的聯系，使得debugger可以遠程調試程序，并且可以讓程序停在某一設置好的斷點處。然后GDB可以獲取內存信息、寄存器的值以及棧和堆的結構。Capstone對目標程序逆向成匯編指令，FW-Fuzz在一些地址設置斷點，然后能夠讓程序不斷地運行。一旦程序到達了插樁的地址，GDB就可以把運行信息導出。

2. 錯誤檢測

GDB會把錯誤信息以core的形式保存下來。

3. 優化插樁算法

首先從pc寄存器的地址對二進制進行反匯編得到反匯編后的指令集。

找到最近的一個分支。在分支跳轉地址上插樁。

構建一個CFG，在CFG每個跳轉的地址處插樁。

4.測試用例生成

測試用例的生成不僅和協議的格式有關，還和運行時獲取到餓信息有關。
有兩種模式：淺模式和深模式。
淺模式：
把輸入的不同字段發送給目標程序，看哪個字段沒有被處理，沒有被處理的字段就不再變異。
深模式
根據代碼覆蓋率計算每個測試用例的適應度，用隊列保存測試用例，選擇高適應度的測試用例。
適應度計算原則：發現的新路徑越多越好，一個testcase執行的新路徑次數越多越好，越早發現新路徑越好。
分母是執行這個testcase之前發現的所有分支，分子中New_branch是這個輸入發現的所有新的分支，Hit_num(i)是k,$2^k<實際覆蓋次數<2^k+1$。
Find_time是發現第一個新分支時執行的分支數除以這個測試用例總共執行的分支數，那么這個值越小說明發現的越早。（原文寫的是大，感覺有點問題）


變異的方法用的是Sulley的變異方法，根據數據類型去變異。
調度策略會把分低的測試用例給去掉。

實驗

目標程序：
baseline: peach, boofuzz.
衡量指標：edge coverage、漏洞發現數量

部分原文摘抄

On the one hand, as Marius Muench concluded, there are challenges of fuzzing firmware: fault detection, performance axsnd scalability, and instrumentation. These challenges limit the state-of-art greybox fuzzing techniques to gain the insight information of the firmware program to guide the generation of input cases. Some researchers attempt tofuzz thefirmware infull emulation or partial emulation environment. However, thedata flowof thesimulated execution is frequently different from the actual execution, whichmay fail to capture errors in the firmware program. And the type of architecture supported by the simulation is limited by Qemu.

其他相關論文

Muench M, Stijohann J, Kargl F, Francillon A, Balzarotti D. What you corrupt is not what you crash: challenges in fuzzing embedded devices. NDSS. San Diego, California: The Internet Society; 2018.

總結

以上是生活随笔為你收集整理的Fuzzing论文_CONCURR COMP-PRACT E2020_Fw-fuzz的全部內容，希望文章能夠幫你解決所遇到的問題。

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