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并确认错误报告。
