题目： Predicting Buffer Overflow Vulnerabilities through Mining Light-Weight Static Code Attributes
作者： Bindu Madhavi Padmanabhuni, Hee Beng Kuan Tan
单位： School of Electrical and Electronic Engineering, Nanyang Technological University
出版： ISSRE, 2014
解决的问题
抽取轻量级特征，利用数据挖掘的方法来预测缓冲区溢出漏洞。
贡献点
- 能够抓住代码中对缓冲区溢出采取的安全措施
- 采取轻量级的分析方法来预测缓冲区溢出漏洞
局限性
文章中没有提及方法的局限性，只提到下一步打算增加实验来进一步确证方法的有效性。
方法(特征抽取)
本文采用的是过程内分析的方法抽取特征，以槽(sink)为单位，抽取sink类型，输入该sink的数据(source)相关属性，以及与sink和source相关的谓词结点的属性作为特征。
sink分类
我们将sink分为以下7类：
- 字符串拷贝（strcpy， strncpy）
- 字符串连接（strcat， strncat）
- 内存变更（memcpy， memmove）
- 格式化字符串输出（sprintf， snprintf）
- 非格式化字符串输入（gets， fgets）
- 格式化字符串输入（scanf， sscanf）
- 数组元素（或指针）写
input分类
我们将input分为如下4类：
- 命令行：scanf， gets
- 环境变量：getwd， getcwd
- 文件： fscanf， fgets
- 网络：recv， recvfrom， recvmsg
输入验证和sink相关谓词分类
为防止缓冲区溢出，应该在填充缓冲区前对大小进行检查。为防止系统输入被利用，输入需要在传播到sink之前进行检查。因此我们分类输入验证和数组大小检查谓词。
CFG中的一个谓词结点d叫做槽k的输入验证，当：
- k和d都间接使用了同一个结点定义的输入变量
- k控制依赖于d
我们利用槽和谓词结点抽取以下特征：
- String Length of source buffer
- Size of source
- NULL check：如果d中包含NULL或0作为它的一个操作数，那么它就是在做一个NULL检查。字符串终结符检查也包含在NULL检查之中，因为终结符‘\0’等于0
- EOF check：EOF是一个用来标记文件结尾的宏常量定义。如果d中有对EOF或-1的检查，即是在进行EOF检查
- Character check：与k和d相关的输入变量是否为一个字符或一个整数
- Character occurrence in string check：与k和d相关的输入变量是否被当作strchr, strpbrk, memchr等函数的参数传递
- String comparison：与k和d相关的输入变量是否被当作strcmp, strncmp等函数的参数进行传递
- Other check：k有验证结点d，并且d不是以上讨论过的类型
我们将槽的谓词p分为以下几类：
- Size of destination buffer check：p代表k中定义的缓冲区的大小
- Size of destination buffer -1 check
- Size of destination buffer - x check
- String length of destination buffer check：p代表k中定义的字符串长度
- Post size check increment：这个属性表示当p属于以上size check之一，并且在k中定义的缓冲区的index或pointer有增长
槽特性分类
有些槽会有包含溢出的一些特性。例如strcpy和strncpy，后者限定了要被copy的字符的数量，而前者没有。对于槽的特性，我们提出了以下的属性：
- Data buffer declaration：语句q被认为是槽k的数据缓冲区声明，如果k定义了v，而q声明了v。如果目标缓冲区是在考虑到与槽相关的变量的情况下声明的，那么这个槽一般来说是安全的。为抓住这样的特性，我们将槽数据缓冲区声明语句分为如下三种：
- 静态分配：目标缓冲区是静态分配的
- 动态的与源无关的分配
- 动态的与源相关的分配
- Number of elements copied within bounds：此属性对于strncpy是可用的，将要copy到槽的元素数量在槽中指定，并且是常数。它可以有如下四个值：若将要copy的元素数量不大于目标缓冲区的大小则值为1，否则为0，若无法评估则值为2，不应用此属性时值为-1
- Array write index within bounds：只有在常数index以及已知缓冲区大小情况下写数组时使用。可能有如下3种取值：1或0或-1（不可用）
- Format string precision within bounds：有以下3种取值：1或0或-1，如下图第6行的槽，此属性被设为0，因为格式化字符串大小为35，大于缓冲区大小32
- String copy within bounds：对于有字面值字符串作为source，并且已知缓冲区大小的strcpy等槽是可用的。有1和0和-1三种取值。取值为1当字符串字面值小于目标缓冲区大小
- Data dependent on destination buffer size：如果槽的操作数数据依赖于槽中定义的缓冲区的大小，则此属性值加1
- Data dependent on destination buffer size variant：与上面类似，只是将操作数换成了一个在k处定义的变量
- Is character case conversion sink：此属性只对写数组的槽可用，判断一个槽是否是进行大小写转换的槽，可取值0或1或-1
- Resets in control predicates：统计槽目标缓冲区指针在槽控制谓词中被重置的次数
实验
我们利用静态分析和机器学习的方法来预测缓冲区溢出漏洞。实验用的数据集如下图，这5个开源程序都来自MIT Lincoln Labs buffer overflow benchmark。
在此数据集中有139个槽，其中40个包含漏洞。
数据收集
我们在静态分析工具CodeSurfer上实现了我们的工具BOMiner来抽取上文提及的特征。对于下图所示的槽，提取出的特征为：
(7, 3, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 2, 2, 0, 0, 0, 1, -1, -1, -1, -1, 0, 0, 0, 0, 2, FALSE)
分别对应特征：
(Sink, Command Line, .., Files, Network, String length of source buffer, Size of source, …, String Length of destination buffer Check, Data Buffer Declaration Type, Number of Elements Copied within bounds, … Resets in Control Predicates, Post Size Check Increment, Vulnerable?)
实验设计
采用标准10折交叉验证来进行实验，所用机器学习算法有朴素贝叶斯（NB），决策树（J48 graft），多层感知机（MLP），逻辑回归（SL）和支持向量机（SMO）。利用WEKA的默认参数进行训练和测试，利用recall，false alarm，precision和accuracy对模型进行评估。
实验结果
几种模型的实验结果如下所示：
采用同样数据集，利用其他5中工具所得的实验结果如下所示：
相关工作
- 静态分析方法在检测缓冲区溢出漏洞时会模拟缓冲区在程序中的使用，在内存访问越界时发出警告。它们常常使用符号化评估和约束求解的方法。
- 测试用例生成的方法会用到符号化输入和约束求解。我们的方法与这类方法相比的优点在于它更加轻量，因为我们的方法只是利用静态分析来抽取特征。
个人体会
其他不谈，单从试验结果来看这篇文章应该说取得了很大的成功，十折交叉验证基本能够保证结果的客观性，并且作者把他们的工作与其他5种静态分析工具进行对比，发现在缓冲区溢出漏洞的挖掘方面其他工具与本文的工作存在着悬殊的差距。如果作者没有在数据上做手脚，那么我觉得他们下一步确实可以把这个方法应用在实际工程中，去挖掘未发现的漏洞了。
至于在特征选取方面，本文所选取的特征确实能够表征缓冲区溢出漏洞的特性，然而在抽取特征的过程中，有些特征的设定过于笼统，也会出现对一个特征难以赋值的情况，可能需要与数据流分析更加紧密的结合，然而这样做可能会失掉“轻量”的特点，如何在两者之间做出权衡还需斟酌。