世界杯的小组赛第一轮已经踢完了，我们终于又可以回到论文阅读了吧？今天为大家来介绍明尼苏达大学和浙江大学的研究人员（纪守领老师一直是本栏目的投稿大户，而卢康杰老师今年跟我们还合作发表了论文~）在CCS 2022发表的研究论文——Non-Distinguishable Inconsistencies as a Deterministic Oracle for Detecting Security Bugs
在这篇论文中，作者探讨了一个很有趣的研究问题——如果没有事先定义好的、非常明确的bug检测指导规则，我们能否发现代码中的security bug呢？这背后有两重思考：首先，传统的security bug检测方法喜欢给bug分类，然后分门别类地制定一些规则去检测它们，可是即使是很明确的bug类型（例如use-after-free）也存在很多不同的变化，用特定的20条规则去描述，要么太抽象以至于代码分析和bug检测时摸不着头脑，要么太具体而漏掉很多变种，最后就回到了老路子上。接下来，如果要更加灵活而不是“一刀切”，我们就需要用其它的一些指导思想来帮忙，这里面最常见的就是去学习前人总结的一些bug里面的特征，使用代码相似性检测或者AI的方法来进行知识迁移，可是本专栏之前的文章（G.O.S.S.I.P 阅读推荐 2022-10-19 亡羊补牢）就说过“当前主流静态分析方法对这一类重复出现的漏洞进行特性总结的时候，没有真正抓住漏洞的核心语义，而简单地依赖语法特征来生成所谓的‘漏洞签名’”，没法做到真正的广谱抗菌疗效好~”。那让我们看看，本文作者提出了什么新的技术方法。
上图是一个在OpenSSL中发现的wild pointer dereference bug实例（插一句，小编读大一学C语言的时候总是想，wild pointer翻译成“野指针”从音韵上就很难听，能不能叫它“逍遥指针”），在代码的第42行出现了一个未经检查的指针使用，如果该指针被控制了，最严重的情况下可能会导致任意内存地址访问。可是这个问题为什么没有被传统方法发现呢？作者指出，程序分析技术不是万能的，该例子涉及到复杂的data flow analysis（特别是很难处理data flow path非常长的情况），程序分析往往还没分析到这里就失效了；同时，这个问题并不是广泛存在的，你也很难从别处（特别是同一个codebase里面）学到什么知识来帮助相似性分析找到这个bug。于是，我们的作者就拿出了他们的新法宝——基于non-distinguishable inconsistency（NDI）的bug检测方法，我们继续读下去，看看这个方法的妙处是什么。
在论文中，对NDI方法的总结是这么说的：“If an inconsistent state between two paths cannot be recovered after the two paths merge and the involved critical variable is used, it must be a bug”，是不是稍微有点难理解？回到具体情况下，在上图的例子中，代码第5行和第8行“制造”了两种不同的状态（返回值不同），而这两种状态在返回后（代码第18行）汇总到了一起，产生了不一致，后续的程序并不知道这个evp_pkey_get_legacy函数拿到的是空指针还是有效指针。如果我们能发现这种不一致性，并且知道受到影响的值（变量）是很敏感的，那我们是不是就可以找到所谓的non-distinguishable inconsistencies bug呢？Bingo！
在实际中，使用NDI方法检测bug还有很多挑战，其实是要让程序分析工具去理解这里面很多抽象的概念，包括什么是“状态”，什么是“敏感变量”，什么样的路径算是状态不一致而且最终会影响到后续的执行？这些细节在论文的第四章里面进行了介绍，更重要的是，作者开源（确实是开源了，没有404）的代码实现了一个基于LLVM的analyzer，针对bitcode进行分析，检测特定的不一致状态。如上图所示，基于NDI的方法首先在LLVM IR（bitcode level）上收集paths pairs，看这些成对的路径有没有存在不一样的状态（并传播到后续使用），找到这种特定的pair之后，就去检查里面用到的值对程序执行的影响：想象一下，如果有一个状态不一致的变量，后续使用的时候又缺乏检查（或者所谓的recovery，就是把它状态强制归一），这种“薛定谔状态”的变量肯定大概率会导致bug甚至漏洞吧！
让我们看看这个方法的实际效果，首先看看性能，不管是从分析的时间还是分析的内存开销来看，都很符合现代程序分析环境的要求：
接下来看一下作者基于NDI方法发现的bug：
作者还和两个基于代码相似性检测的工具——IPPO和Crix（其实都是作者自己以前的论文中的工具）——进行了对比，发现它们远远比不上基于程序分析的方法效果好！
同时，作者也跟另外两篇论文（Finding Bugs Using Your Own Code: Detecting Functionally-similar yet Inconsistent Code @ USENIX Security 2021 和 Progressive Scrutiny: Incremental Detection of UBI bugs in the Linux Kernel @ NDSS 2022）里面的工具进行了横向对比：
最后，说点不想说或者有人不想让说的话吧，作为可能是全球第一批参加线上学术会议（SANER 2020，当年2月在加拿大召开，会议开始前中国作者无法前往）的作者，我们在会议报告的最后对不幸去世的医护工作者表示了哀悼。快三年了，我们今天在阅读推荐的最后，为火灾的死难者默哀，默哀不代表我们没有自己的声音，坚持写作就是最好的发声，在用学术同无力感和焦虑抗争的路上，我们会继续！
论文PDF: https://nesa.zju.edu.cn/download/zqy_pdf_ccs22_ndi.pdf
GitHub: https://github.com/umnsec/ndi
原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-11-25
