Automatic Inference of Search Patterns for Taint-Style Vulnerabilities

题目： Automatic Inference of Search Patterns for Taint-Style Vulnerabilities
作者： Fabian Yamaguchi, Alwin Maier, Hugo Fascon, Konrad Rieck
单位： University of Gottingen, Germany
出版： S&P, 2015

名词解释：污染型漏洞

污染型漏洞这个词产生于污点分析中。污点分析是一种在程序中追踪数据传播的技术。污点分析的目标是识别出从攻击者控制的源未经输入检查就流向安全敏感的槽的数据流。这个过程需要三个定义：
- 合适的源
- 相关的槽
- 输入检查规则

污染型漏洞可以包括：缓冲区溢出，SQL注入，命令行注入，缺少授权检验漏洞

解决的问题

在软件发展过程中污染型漏洞是一个持续性存在的问题。在这一类漏洞中，攻击者控制的数据从一个输入源未经检查就传给了一个敏感的槽。这一类漏洞中简单的可以被自动检测到，然而包含工程特定API或者跨越多个函数的复杂例子就需要人工检查。
本文提出为污染性漏洞自动推断模式的方法。给出一个安全敏感的槽，我们自动识别出与之相关的源-槽系统并且构建出模拟这些系统中数据流和输入检查的模式。

贡献点

对代码属性图的扩展：增加了语句优先级信息，并且使得利用图数据库查询进行过程间分析成为可能。
对调用模式的抽取：提出了一种新颖的构建调用模式的方法，方法利用聚类算法，并用到了参数的定义和它们的输入检查。
对于模式的自动推断：本文阐述了调用模式是怎样被转换为图遍历形式的调用模式的。

方法

代码属性图的扩展

我们通过以下方式扩展代码属性图：在函数调用点的实参和被调用函数的行参之间添加边，以及在调用点和被调用函数返回语句间添加边。

A.添加后序支配树

与控制流图和程序依赖图一样，每个语句在支配图中都表示为一个结点。这些结点被表示“支配”的边相连。这里支配的定义是：在一个控制流图中，一个结点d支配另一个结点n，当每条经过结点n的路径都需经过结点d。为了把每个结点与它的直接支配相连，我们获得了一个支配树。类似地，一个结点p后序支配一个结点n，当每个通过n的结点都需要通过p。为了把每个结点与它的后序支配相连，我们获得了一个后序支配树。
考虑下面的代码：

它的后序支配树如下图所示：

由图可以看出，对boo的调用被谓词直接后序支配，而它直接后序支配int z。

B.检测参数的修改

后序支配树建立起来之后，我们可以将它应用在检测导致参数变化的函数调用上——这在编译器设计上被称为定义参数(defining arguments)。对于一般的库函数，我们可以用标注来进行处理，而内部API并不会被认作输入源。为解决这一问题，我们进行以下处理：对于每个遇到的没有源码的函数，我们通过以下来判断它有没有定义它的参数。
- 检查是否有未经输入检查的局部变量声明（例如赋值或对构造函数的调用）到达了参数
- 检查在此函数到它后序支配树中的变量声明的路径中不含其他与该局部变量声明在数据流上直接相连的语句

计算此函数所有调用点中满足以上两个条件的调用点所占比例，如果超过一个阈值则认为它定义了它的参数。我们将此阈值设定为10%。根据这种简单的启发，我们可以重新计算代码属性图中无源码函数的调用点。

C.数据流信息的传播

不只是库函数会发生参数定义，事实上，任何函数调用都有可能会发生参数定义。为了考虑到间接的参数定义，我们可以利用调用链来传播数据流信息：检查每个有源码的函数，如果它的参数在函数内部被定义了，并且定义通过控制流到达了出口，那么认为它的参数被定义了。为了确保函数参数定义被准确识别，我们递归地检查函数中的函数调用，如下面算法所示。

推断漏洞的搜索模式

从一个安全敏感的槽开始，例如内存函数memcpy，我们的目的是生成图遍历形式的搜索模式。这些模式需要具有一般性，并且它们需要精确地抓住跨函数的数据流。最后，生成的模式需要易于理解并且可修改。
为达到以上要求，我们分四步来生成搜索模式：

A.生成定义图

为了有效发掘参数是如何定义以及检查的，我们需要一个源-槽的表达，这种表达只包含参数的定义和输入检查，而忽略其他所有语句。为解决此问题，我们为每个源-槽系统生成了一个图表达，成为定义图。
要构建定义图，首先局部地为单个函数建模，然后将相关的图结合起来。

局部函数建模

按照以下规则遍历代码属性图，得到图表达：
- 对于选定的槽，我们沿着语法树的边到达它的参数
- 对上步得到的参数，我们沿着与之相连的数据流和控制依赖找到定义语句以及控制调用点的条件
- 最后，我们利用过程间的边，从所有定义了我们参数的函数调用走向相应的函数体，在那里进一步识别出影响了我们选定的槽的定义语句

我们将所有与槽参数定义相关的函数也视作槽，递归地应用上面的三个规则，获得一个树。

定义图

这样一个树并不能处理槽所在函数的传入参数。对于这种情况，我们简单地对整个函数进行模拟，并且将参数绑定到待分析函数。
定义图的定义：调用点c的定义图G=(V, E)是一个图，图中V包括局部模拟c，以及c的直接和间接调用者所在函数的树。对于每一个属于V的a, b，如果a表示的函数调用了b表示的函数，那么存在边属于E从a指向b。

B.解压缩与聚类

给出任意一个定义图的集合，例如对memcpy函数的所有调用点的定义图集合，我们要从中识别出反映普遍参数定义的模式。为此我们利用机器学习的方法为定义图生成聚类。有如下步骤：
- 定义图解压缩

以上算法给出了获得定义图中所有树的组合的算法。定义图中每个结点代表一棵树，其中r(V)是定义图的根结点，[v0]代表一个只包含结点v0的列表，符号+代表向列表中添加元素。
- 聚类被调函数和类型
利用complete-linkage clustering对被调函数和类型进行聚类，使用Jaro距离来进行聚类，通过实验将参数固定为0.8。

聚类定义图中的组合
我们将被调函数和参数类型的聚类组成一个词袋，将定义图的每一个组合利用词袋模型映射为一个向量，每一维代表被调函数和参数类型中的一类。对这个向量集合进行linkage聚类，利用曼哈顿距离，参数固定为3。

C.生成输入检查规则的覆盖图

我们将之前抽取的每一个条件表示成为一个语法树，然后将每棵语法树映射为一个向量，利用linkage clustering对此向量进行聚类。

D.生成图遍历

为生成图遍历模板，我们定义敏感槽的名字，对每个参数数据源的描述，以及对输入处理的描述。它们对应于argiSource 和 argiSanitizer，其中i代表参数的序号。遍历通过对所有的sink的调用点进行，然后利用taintedArgs 和 unchecked 分别遍历每个sink。如下图所示：

其中 taintedArgs 用来寻找sink是否符合source的描述(argiSource)。为达到此要求，首先生成相应的定义图。然后并不对图进行解压缩，而是确定调用点是否能够满足参数描述，这通过查看对每个描述，在定义图中是否至少存在一个匹配的语句来进行。
这一步大大减少了需要分析的调用点数量。然而我们还不能知道调用点是否匹配参数描述。为达到此目的，我们解压缩定义图，由此就能够得知参数定义是否匹配了。最后，我们返回所有与描述匹配的定义组合，将它们传递到unchecked。
unchecked代表所有的根据输入检查描述至少存在一个未经检查参数的调用点。通过将定义图中的每个条件与输入检查描述进行检查来完成。
为了对模式进行检查，我们通过将参数定义和条件定义分别翻译为参数描述和输入处理描述来进行。对于每个参数，一个数据源和条件的集合是可以得到的，这些仅仅需要被总结为一个容易被专家分析的形式。至此，我们为这些聚类生成正则表达式，通过确定通用的子字符串。结果可以用来挖掘包含漏洞的代码，也可以提供给专家进行修改。

实验

controlled experiment

验证实验

利用5个开源应用的已知漏洞来评估我们的方法。

对每个工程，我们确定了一个最近的污染型漏洞，数据集和结果如下表：

表中列出了对于上述漏洞是否找到了正确的源和正确的输入检查，生成的模式个数，生成模式的时间，执行模式挖掘所用的时间，以及减少对调用点人工检查的比例。

具体案例：heartbleed漏洞

我们利用我们的方法在OpenSSL 1.1.0f版本中为槽memcpy生成了pattern并进行了漏洞挖掘，过程如下。
- 对程序中几个库函数进行检查，得出它们被定义的参数如下表。

- 找到与memcpy对应的源如下表。

- 对这些源进行检查，发现n2s是受攻击者控制的源，然后执行如下图所示的模式。

- 可以看出，我们生成的输入检查规则很容易被安全专家修改。按此模式遍历整个工程，从738个调用点中返回了7个，如下图所示。人工审查后发现了两个heartbleed漏洞如阴影所示。

局限性

方法只适用于工程中大部分函数不含污染型漏洞的情况，如果多数函数都没有进行输入检查，那么我们的方法将无法生成正确的模式。
对全局变量和共享内存无法处理。
目前只实现了对C语言程序的检测。
对一些动态调用和并行执行的情况无法处理。

个人体会

这是我读过的论文中最复杂的一篇，也是启发最大的一篇，读完之后觉得这种污染型的漏洞就应该用对数据流进行检查的方法来检测。因为论文中方法生成的模式都很简单，所以我先尝试一下将数据流分析与决策树模型进行结合，具体细节还在考虑。