如何利用 KLEE 符號執行引擎挖掘軟體漏洞

具體示例如下，其中輸入x未知，即符號：

符號執行在所有三個執行路徑(x < 0, x > 100, 0 < = x < =100)並生成三個具體的測試用例：x=-1, x=101和x=23在擊中斷言之後。

你不再需要手動編寫測試用例，你會沿執行路徑捕獲斷言失敗和記憶體安全漏洞。以上說的可不是理論層面上的事情，哪這種方法可以在實踐中用於實際程式嗎?

KLEE是一個符號執行引擎，可對任何輸入執行未修改的真實程式。你將程式編譯為LLVM位碼，將某些輸入標記為符號，然後啟動KLEE。 KLEE使用約束解決方案探索可能的執行路徑，併為每個路徑生成具體的測試用例。如果發生漏洞，你可以使用觸發它的輸入來重播程式。

2019年11月，關於KLEE的OSDI 2008開創性論文被選入ACM SIGOPS名人堂。在過去的十年裡，KLEE的研究和應用產生了超過150篇科學出版物、數十篇博士論文、研究資助、工具和安全初創公司。

在2007年，我一直努力尋找自己的研究論文，直到遇到Cristian Cadar的論文“EXE: Automatically Generating Inputs of Death“EXE: Automatically Generating Inputs of Death”。受到符號執行思想的啟發，在將傳入的網路資料包傳遞到網路堆疊之前，可以標記它的協議報頭嗎?如果是這樣，我可以用這種技術找到協議規範和實現漏洞嗎?

於是研究人員寫了一封電子郵件給Cristian Cadar，並迅速收到了答覆。而且，Cristian和Daniel Dunbar慷慨地向它傳送了KLEE的原始碼，這是他們正在使用的新工具，目前還尚未對外公佈。

接下來我擴充套件了KLEE以執行相互通訊的多個協議棧。我將此技術用於測試感測器網路，並在我的IPSN 2010論文中描述的Contiki OS中發現了兩個有趣的漏洞。其中一個導致了TCP/IP堆疊內的感測器節點的死鎖，需要重新設定硬體，這是在感測器網路部署中觀察到的真正漏洞。死鎖是指兩個或兩個以上的程式在執行過程中，由於競爭資源或者由於彼此通訊而造成的一種阻塞的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的程式稱為死鎖程式。

自2015年以來，我一直沒有過多使用過KLEE，並且想再次嘗試一下。同時，Contiki OS已複製到Contiki-NG。我複製了儲存庫，並將稱為20-packet-parsing的測試用例編譯為LLVM位碼。在測試用例中，我使用KLEE的klee_make_symbolic函式標記了測試資料包緩衝區(〜1KB)的符號。Contiki-NG是一套用於下一代IoT(物聯網)裝置的開源跨平臺作業系統，可適用於獨立高防伺服器。

在我的舊Mac上執行了幾分鐘後，KLEE在解析某些協議的標頭時發現了兩個記憶體漏洞(指標超出範圍)。我將這些發現與具體的測試案例一起報告給Contiki-NG的安全團隊，以進行進一步的分析。對我來說，這個小測試是KLEE仍然是有用的研究和測試案例生成工具的又一個證據。

將符號執行應用於任意真實程式很難，你通常必須對執行環境建模，並找到有效的方法來應對不確定性和路徑爆炸。 而且，許多路徑約束很難解決，但是對於當今的求解器而言難以及時解決。

儘管如此，研究和應用符號執行(使用KLEE)仍會帶來許多機會。你將瞭解程式結構，編譯器，SAT / SMT求解器，以及如何編寫其他型別的測試工具。基於這些知識，我編寫了模糊Android應用程式的工具，超級最佳化LLVM IR，以及最近在工作中使用拼寫編寫的模糊衛星控制程式的工具。