IMChecker
1.0.0
thu，Imchecker Group，通過[email protected]與我們聯繫
圖書館通過應用程序編程接口（API）提供可重複使用的功能，並具有使用限制，例如呼叫條件或訂單。違反約束，即濫用API，通常會導致錯誤和安全問題。儘管研究人員在過去幾十年中開發了各種API-MISUSE探測器，但最近的研究表明，API濫用在現實世界項目中很普遍。現有的方法要么遭受使用稀疏的使用問題（即，很少發生的錯誤）或由於語義不准確而報告的錯誤警報。為了克服這些局限性，我們介紹了Imchecker以有效檢測API-MISUSE錯誤。 Imchecker背後的關鍵見解是一種約束指導的靜態分析技術，該技術由特定於領域的語言（DSL）提供動力，用於指定API使用約束。通過研究現實世界中的API-misuse錯誤，我們提出了IMSPEC DSL，該錯誤涵蓋了大多數API使用限制類型，並實現了簡單但精確的規範。此外，我們設計和實施Imchecker以自動解析IMSPEC檢查目標，並使用靜態分析引擎來識別具有豐富語義的潛在API濫用和修剪誤報。我們已經實例化IMCHECKER進行了C程序，並根據廣泛使用的基準和大型現實世界的計劃對其進行了評估。
目前，已經發現了75個未知的錯誤，並在Ubuntu 16.04中的Linux內核，OpenSSL和軟件包中確認並修復了61個錯誤。我們正在盡力將Imchecker應用於更多程序。我們將詳細信息上傳到esturation_data/new_bugs中
我們的研究手稿和工具手稿正在ICSE'19的審查過程中。我們將在審核過程完成後立即上傳它們。 （好吧，您可以通過電子郵件將其發送給我們以僅通過學術目的訪問它們。）
我們的工具演示視頻可從英文版本提供：https：//youtu.be/ygdxeyoevim中文版本：https：//www.youtube.com/watch?v=3zanegtwuto
在工具/readme.md上使用工具
Imchecker仍在開發中，並包含許多錯誤和待辦事項列表。任何錯誤或功能請求，都可以隨意通過[email protected]或開放問題給我們發送電子郵件。
為了更好地了解實際C項目中發生了哪些類型的API-Misuse錯誤，以及開發人員如何在實踐中修復它們，我們手動研究了2017年三個開源項目和Linux-Kernel一半年度的兩年版本歷史，如下表所示。之所以選擇這些歷史，是因為持續的發展，並且由於在不同的蟲子檢測工作中經常被提及。總的來說，我們研究了大約135.7萬個LOC和51.1k的提交。
| 專案 | loc | 研究期 | 總投入 | 錯誤修復 | API濫用 |
|---|---|---|---|---|---|
| 捲曲 | 112.8k | 20160101-20171231 | 2613 | 135 | 38 |
| Gnutls | 35.8k | 20160101-20171231 | 2769 | 86 | 30 |
| Openssl | 454.2k | 20160101-20171231 | 6487 | 344 | 115 |
| Linux | 12.96m | 20170701-20171231 | 39295 | 995 | 362 |
| 全部的 | 15.7萬 | 兩年 | 51.1k | 1560年 | 509 |
為了幫助讀者提取提交消息，更改的文件和修補文件，我們開源了我們的gitgrabber工具。我們還上傳了研究主題中與API-Misuse錯誤有關的所有提交，以供進一步使用。
讀者可以在經驗性的文件夾中找到它們。 Gitgrabber上的任何問題，請隨時與我們聯繫！
我們在其最新版本中選擇了廣泛使用的基準，即朱麗葉測試套件v1.3，以及兩個現實世界中的程序：Linux內核-4.18-RC4於2018-7-9發行，並於2018-6-20發布了OpenSSSL-1-1-1-PRE8，以評估我們的方法。我們從兩個角度評估我們的方法。
我們還通過語義交叉檢查和clang-sa一個開源靜態分析工具來測試APISAN的APISAN API使用檢測工具。
我們在estaulion_data上上傳API-Misuse基準和原始結果。
Imchecker的主要動機是在實際程序中檢測API-Misuse錯誤，即確定Imchecker是否可以找到以前未知的錯誤。因此，我們將Imchecker應用於兩個著名的開源程序的最新版本：Linux內核-4.18-RC4和OpenSSL-1-1-1-PRE8，以及Ubuntu 16.04的包裝。目標API是從實證研究中濫用的目標中選擇的。
到目前為止，已經發現了56個未知的錯誤，開發人員已經確認了36個錯誤。
| 專案 | 錯誤（等待響應/確認/修復） |
|---|---|
| Openssl | 17（0/5/12） |
| Linux | 30（5/20/5） |
| DMA | 1（0/0/1） |
| 出口 | 2（0/0/2） |
| hexchat | 2（1/1/0） |
| httping | 1（0/1/0） |
| ipmitool | 1（0/1/0） |
| 開放式VM-Tools | 2（0/0/2） |
| IRSSI | 2（1/1/0） |
| 保存 | 2（0/0/2） |
| THC-IPV6 | 2（0/0/2） |
| Freeradius-Server | 2（0/0/2） |
| 販運者 | 3（3/0/0） |
| Tinc | 2（0/0/2） |
| sslplit | 2（0/0/2） |
| rdesktop | 2（2/0/0） |
| proxytunnel | 2（2/0/0） |
| 全部的 | 75（16/29/32） |
我們將詳細信息上傳到esturation_data/new_bugs中
描述API使用限制的行為規格已被證明對開發人員有效利用API以及通過確保驗證目標API的用法來應對稀疏使用問題是有用的。例如，Bodden提出了Crysl，以彌合密碼專家與開發人員之間的認知差距。但是，當前的規範語言要么是為完整程序屬性而設計的，例如BLAST，JML，要么太具體而無法應用於通用API-USAGE檢測，例如SLIC。我們為名為IMSPEC的API使用約束引入了一種輕巧的域特異性語言。 IMSPEC同時確保了目標API的驗證，即使使用很少，也可以指導濫用檢測。 IMSPEC的實例是一個填充一組約束的模式，可以正確使用API，任何違規行為都會導致API-MISUSE錯誤。
我們將IMSPEC實例上傳到IMPSEC文件夾中，我們將逐步更新此文件夾以獲取更多API。此外，IMSPEC可以用於其他目的，例如生成測試案例，驗證等。此外，我們在工具上提供了GUI IMSPEC作者。
當前，IMSPEC是通過手動寫作創建的。但是，我們確保可以從規範挖掘技術自動生成它。我們正在盡力進行實驗並實施解析器，將採礦工具的結果轉化為IMSPEC，例如Apex。但是，這些工具無法解決所有使用限制。我們還想邀請開發人員幫助我們根據用戶手冊（例如OpenSSL）來完善IMSPEC實例。
正確的API-USAGE必須滿足一組用法約束，即違反約束可能會導致API-MISUSE錯誤。 Imchecker使用IMSPEC的規格自動在源代碼中自動檢測這些錯誤。要處理複雜的現實計劃，Imchecker的基本機制必須可擴展，同時犧牲最低限度的準確性。我們詳細介紹了Imchecker的設計細節，包括使用靜態分析技術來構建分析上下文，在分析上下文中檢測API-MISUSE錯誤的方法，以及使用語義信息和用法統計信息過濾誤報的方法。
我們使用一個激勵人物來說明Imchecker的工作流程。這是CVE-2015-0288中報導的OpenSSL中的一個API-Misuse錯誤。 X509_get_pubkey()的缺失錯誤代碼檢查導致在第4行中的null指針解除錯誤。
1 // Location: crypto/x509/x509_req.c: 70 2 X509_REQ *X509_to_X509_REQ(...){
3 ...
4 pktmp = X509 get pubkey ( x );
5 // missing error code check of pktmp
6 + if ( pktmp == NULL )
7 + goto err ;
8 i = X509_REQ_set_pubkey ( ret , pktmp ); 9 EVP_PKEY_free ( pktmp );
10 ...
11 }
12
13 // Location: /crypto/x509/x509_cmp.c: 390
14 int X509_chain_check_suiteb (...){
15 ...
16 // check error value in usage
17 pk = X509 get pubkey ( x );
18 rv = check_suite_b ( pk , -1 , & tflags );
19 ...
20 }
21 // Location: /crypto/x509/x509_cmp.c: 359
22 static int check_suite_b ( EVP_PKEY * pkey ,...){ 23 ...
24 // ensure pkey not NULL
25 if ( pkey && pkey -> type == EVP PKEY EC )
26 ... // usage of pkey
27 }這是Imchecker的工作流程：
Imchecker將源代碼和API用法約束作為輸入，並以具體位置以及作為輸出的原因生成錯誤報告。首先，API用法約束以輕巧的域名語言編寫；例如， “必須使用null檢查X509_Get_pubkey（）的返回值” 。通過採用這些規格，Imchecker直接驗證了目標API的用法，從而緩解了稀疏使用問題並指導錯誤檢測過程。然後，我們在三個階段中檢測到API-Misuse錯誤。 （1）在階段1中，分析上下文是通過構建控制流程圖並為規範中定義的每個目標API創建程序路徑跡線來構建的，該軌跡通過使用點對點，範圍和路徑敏感分析來使用不受約束的符號執行。在此示例中，如上圖路徑跡線所示，生成了兩個軌跡T1和T2。這樣，Imchecker可以成功捕獲X509_get_pubkey() ， EVP_PKEY_free()的用法上下文和之間的使用情況。 （2）在第2階段，Imchecker採用痕跡來檢測對約束作為潛在錯誤的違規行為。前提，發現X509_get_pubkey()的Tribi-Misuse實例，用於缺少標記為潛在錯誤的錯誤代碼檢查。 （3）在第3階段，Imchecker通過利用多個使用實例和語義信息來提高檢測精度。然後，將第二次濫用濾光到第25行中的X509_to_X509_REQ()中進行的檢查。
可以在此處找到我們的工具的使用：工具/readme.md
在研究Imchecker生成的錯誤報告時，我們發現了一些有趣的錯誤，並在開源開發人員的錯誤報告過程中獲得了有用的經驗。我們分享以下經驗。
作者要感謝Linux內核和OpenSSL的開發人員，以幫助我們完善IMSPEC並確認錯誤報告。
