論文：Finding Bugs Using Your Own Code: Detecting Functionally-similar yet Inconsistent Code
今天分享的論文是美國東北大學盧龍教授團隊在usenix security2021發的一篇關於機器學習檢測漏洞的論文

文章目錄

• 簡介
• 背景
• 方法
• 結果
• 侷限性
• 總結

簡介

概率分類在檢測已知型別的漏洞取得了很好的效果。但是這些方法需要很大的資料量來訓練模型。論文提出了新的基於機器學習的漏洞檢測技術。這種技術不需要外部程式碼或樣例來訓練。而是從檢測漏洞的程式碼庫上訓練，然後就不需要去收集和清洗訓練資料。

這個技術的關鍵是對給定的程式碼庫的聚類。聚類過程會去識別工程裡的程式碼片段，這些程式碼片段功能相似但是以不同的形式出現。這種不一致性就會導致一系列的bug，從缺少檢查到不安全的型別轉換。不像前面的工作一樣，這個技術是通用

背景

近些年，使用機器學習去檢測漏洞的工作還是比較多的。現有的工作基本是按一個思路來做，在一個已知漏洞的資料集上訓練模型，然而用訓練好的模型去真實環境中檢測相似的漏洞。這些工作在檢測已知漏洞上具有很高的有效性。然而，這種“learn-from-bug”檢測技術面臨著兩個侷限性。

• 需要大量已知漏洞的資料集去訓練，收集和清洗資料的工作都比較複雜。
• 模型通常是針對某一種漏洞進行訓練和檢測的，是bug-specific。而且，不同型別的漏洞檢測的準確性還是相差比較多的。

方法

論文提出了FICS，其工作流程如上圖所示。

• 首先從給定的程式碼庫中提取程式碼片段。
• 先對功能相似的片段進行聚類
• 再對實現不一致的進行檢測。
• 手工分析，對bug分類

對於這個FICS來說有兩個比較難以解決的挑戰：

• 找到一個合適的程式碼粒度去有效地找到功能性和不一致性
• 使方法可以擴充套件到大型的程式

針對以上問題，論文提出了一種過程內的粒度，命名為Construct，實際上就是可調整大小的過程內資料依賴圖的子圖。結果表明，這種粒度足夠提取出程式碼相似性和不一致性，而且也足夠小可以讓聚類演算法擴充套件到大型程式上。
另外，還提出了兩種圖嵌入技術，一個叫bag-of-nodes，一種用於第一步聚類的粗粒度的嵌入方法。一個叫graph2vec，一個細粒度的圖嵌入技術用來第二步聚類。這兩種技術能夠在不同尺度下準確地比較Construct的相似性和不一致性。

再具體的話，上面的四個步驟可以再細分為9個步驟。具體如下圖所示。
（1）首先將C程式碼編譯為LLVM 位元組碼，然後用過程內的資料流分析去提取每個函式的程式碼片段的基本操作和計算。
（2）在提取完Constructs後，FICS對Construct抽象為一個通用的形式，進而為後續的聚類做準備。
（3）第一步聚類將功能相似的Construct組在一起，在一個組裡去看一致性和其他不同的construct
（4）最後做誤差分析，去識別出不一致性指出的bug。人工再去驗證，分類漏洞。

結果

主要針對以下四個問題，進行了評估：

• 論文提出的方法檢測漏洞有多有效？
• 論文提出的方法是否能夠找到未知的漏洞，而不需要人工過多的驗證？
• 什麼是非漏洞的不一致性？是否需要修復？
• 論文方法的擴充套件性有多好？

設計了一個對比實驗，測試物件是iBench。分別和其他工具APIsan，Crix，LRSan進行對比。

第二步是去針對五個開源軟體去發現未知的漏洞。

最後確認了22個漏洞。

另外，還提到了效能方面的評估。在20核，200GB的記憶體的工作站上只花了5小時跑完了其中三個程式。其他兩個OpenSSL和Qemu花了12和72小時去分析。

侷限性

由於是從被檢測物件的程式碼庫進行學習的，如果程式碼量比較小，學習的效果就會比較差。但是太大的程式碼庫，比如linux核心，也是處理不了的。因為執行基於圖的程式碼相似度比較需要超過16000的編譯單元，而這需要大於200GB的記憶體空間。
一些小的bug（one-liners）也是解決不了的。因為FICS最小的Construct粒度包含一個完整的基本塊，仍然要比這些tiny bug要大得多。
研究的原型不支援C++，因為資料依賴圖（DDG）的提取步驟不能處理C++特定的指令，比如涉及到向量或者異常處理的操作。

總結

這篇論文的主要核心點是用聚類的方法來檢測漏洞程式碼，所以不需要給程式碼打標籤啥的。之前就想過漏洞檢測相關的資料集比較少，怎麼用機器學習來做還是個問題，現在果然有工作是做這塊的。看起來效果不錯，還發現了新的漏洞。
相比以前的工作針對特定漏洞進行檢測，這篇漏洞檢測的方法更通用。或許其他相關漏洞的工作也可以借鑑這裡頭的思路。