<p style="text-align: center;">今天要给大家推荐的论文是来自<a href="https://mp.weixin.qq.com/s?__biz=MzA5MzQ1MDI2MA==&amp;mid=2456041846&amp;idx=1&amp;sn=45db2c6fabe2c61db50d4675c051ce46&amp;scene=21#wechat_redirect" target="_blank">中国科学院信息工程研究所陈恺研究组</a>投稿的最新研究AURC: Detectiong Errors in Program Code and Documentation，目前该工作已发表于USENIX Security 2023。</p><p style="text-align: center;"><img src="https://datacon-pro-public.oss-cn-shenzhen.aliyuncs.com/rich_text_image/1684464191713_467af63a.png" alt="" data-href="" style=""></p><h2 style="text-align: start;">研究背景</h2><p style="text-align: start;">随着软件行业的发展，现代软件功能越来越多样、结构越来越复杂。为了降低开发成本、缩短开发周期，一些通用的功能被封装成一个模块，通过API向外提供服务，而API文档则是描述这些API使用的重要参考。发现API相关的错误至关重要，因为在API连接起来的软件供应链上，上游软件的安全问题可能导致一系列下游软件的安全风险，Log4shell漏洞就是一个例子。为了发现API相关的错误，现有工作的一个重点在于找到API的正确使用方式，以此为参考来发现那些错误的API用例。有的工作通过大多数投票来决定正确的API使用方式；有的工作假设文档是正确的，以此来寻找代码中错误的API用例；有的工作通过分析相似上下文中API使用的异同来发现错误的API用例。但是，这些方法被如下场景掣肘：（1）文档中只包含了一部分API的介绍，并且文档本身可能是错的；因此基于文档进行API缺陷发现的方法无法分析不包含文档的API、也无法应对文档错误的情况。（2）大多数投票的结果可能是错的，广泛的使用方法并不意味着它是对的。（3）上下文中并不一定存在正确的用法。</p><p style="text-align: start;">作者观察到在API使用的场景下包含三个对象：文档、调用者、被调用者，它们均能作为API使用方法的参考（API Usage Reference, AUR for short)，如果将这三个对象进行互相比对，可以摆脱缺陷发现中对文档、大多数投票、上下文的依赖。并且，因为不假设文档是正确的，而是将其作为比较的对象之一；这种方法不仅能发现代码的错误，还能发现文档的错误。</p><h2 style="text-align: start;">方法</h2><p style="text-align: start;">AURC(API Usage Reference consistency Checker)的总体架构如下图所示。针对函数的返回值问题，AURC主要分为四个部分：从文档提取API返回值，从被调用者（即API源码）中提取返回值，从调用者中提取API的返回值，将三个对象进行交叉检验来发现错误。</p><p style="text-align: start;"><img src="https://datacon-pro-public.oss-cn-shenzhen.aliyuncs.com/rich_text_image/1684464200400_ef6d0b51.png" alt="" data-href="" style=""></p><p style="text-align: start;">针对从文档中提取返回值，AURC首先通过预训练模型将文档中描述返回值的句子过滤出来。在这些句子中，有一些暗示范围、数值的自然语言，因此，AURC进一步通过一个映射表将这些值转换为可以进行比较的数字形式。</p><p style="text-align: start;">针对从API源码提取返回值，作者发现返回语句处于函数执行路径的末尾，如果进行从头到尾的前向分析，运行开支很大。并且，在C项目中返回值作为传递错误码的途径，它的值受之前的数据流影响不大。因此，AURC采用Context-sensitive Backtrace Prediction，从执行路径尾部开始寻找返回语句的到达定义（Reaching Definition）以获得返回值，这样大大节省了进行程序分析的成本。此外，该方法还通过分析返回值所处的上下文环境对其可能的范围进行推测，来提高分析的精度并应对无法根据到达定义获得返回值的情况。</p><p style="text-align: start;">AURC通过收集并分析return check从调用者处提取返回值。作者发现调用者对API返回值的检查可能分布在不同的条件语句里，因此借助于数据依赖图将这些检查聚合在一起以提高对return check分析的精度。此外，AURC还通过Range Deduction Tree（RDT for short），一种基于控制流图中基本块顺序的return check组织方式来对返回值进行推断。</p><p style="text-align: start;">从上述三个对象中获得信息后，AURC进行互相检验并推断正确性。作者通过对大量补丁的分析和与开源库维护者的交流，总结出4条推断规则：</p><ul style="text-align: start;"><li>Rule 1: The caller has bugs if it is inconsistent with the callee and the document.</li><li>Rule 2: The document has bugs if it is inconsistent with the callee and the caller.</li><li>Rule 3: When the document does not exist, the caller has bugs if it is inconsistent with the callee.</li><li>Rule 4: If the callee is inconsistent with the document and the caller or all AURs are inconsistent, further manual check is needed.</li></ul><h2 style="text-align: start;">效果</h2><p style="text-align: start;">作者在十个开源库上进行了测试，新发现了529个代码缺陷和224个文档缺陷，总体的Accuracy为87.9%；其中236个代码缺陷和103个文档缺陷已经被库的维护者接收与合并。虽然仍有一些存货没有提交，通过修复AURC在OpenSSL上发现的代码与文档缺陷，作者在OpenSSL贡献者中获得了25/768的排名，这体现了AURC在开源社区的实际意义。</p><h2 style="text-align: start;">插曲</h2><p style="text-align: start;">作者一开始基于tree-sitter实现AURC，在审稿过程中接受审稿人的建议重新基于LLVM实现了AURC。不过，作者仍然相信tree-sitter在代码分析中的积极作用，因此将tree-sitter based AURC中的一些代码抽取出来形成了一个用于代码分析的库cinspector：https://github.com/PeiweiHu/cinspector 。这个库仍在开发中，但是欢迎大家尝试使用，作者会积极回应使用中产生的问题。</p><p style="text-align: start;">论文下载：https://www.usenix.org/system/files/sec23fall-prepub-437-hu-peiwei.pdf</p><hr/><p style="text-align: start;">投稿作者介绍：</p><p style="text-align: start;">胡佩威 中国科学院信息工程研究所<br>中国科学院信息工程研究所博士研究生，主要研究方向为软件逆向与漏洞挖掘，主导和参与的研究成果发表于USENIX Security、CCS、ACSAC；积极参与开源社区，为Rizin、OpenSSL、Linux Kernel做出贡献。</p><p><br></p>

软件安全

AURC: Detectiong Errors in Program Code and Documentation

今天要给大家推荐的论文是来自中国科学院信息工程研究所陈恺研究组投稿的最新研究AURC: Detectiong Errors in Program Code and Documentation，目前该工作已发表于USENIX Security 2023。