一种基于静态分析技术的源代码安全检测模型

《一种基于静态分析技术的源代码安全检测模型》由会员分享，可在线阅读，更多相关《一种基于静态分析技术的源代码安全检测模型（7页珍藏版）》请在金锄头文库上搜索。

1、http:/ - 1 - 一种基于静态分析技术的源代码安全检测模型一种基于静态分析技术的源代码安全检测模型1 粱婕，张淼，徐国爱，杨义先 北京邮电大学网络与交换技术国家重点实验室，北京（100876） E-mail：liangjie_ 摘摘 要：要： 本文介绍了当前主流的静态代码分析技术， 在分析讨论其优缺点基础上提出了一种 新的静态代码检测模型。 该模型结合了当前成熟的静态分析技术， 并借鉴了编译器中数据流 和控制流分析的思想， 获取上下文关联的数据信息， 从而更加准确地分析代码中存在的安全 问题。 关键词：关键词：数据流分析，控制流分析，别名分析，静态代码分析，源代码检测 1. 引言引言

2、随着社会信息化的不断加深， 人们不得不开始面对日益突出的信息安全问题。 研究表明，相当数量的安全问题都是由于软件自身存着的安全漏洞引起的。 软件漏洞的产生， 一方面可能是设计人员在架构阶段没有明确用户对安全性方面的需求， 在设计上没有考虑安全性， 开发人员使用有风险的库函数或者引用没有经过安全性测试的公共代码； 另一方面， 开发人员可能为了测试方便在程序中开后门， 或者别有用心的植入恶意代码。 攻击者利用这些漏洞绕过安全策略，以达到窃取信息的目的。 检测软件安全漏洞，通常从两个方面进行：动态分析与静态分析。在动态分析中，需要根据实际状况， 设计多组极限测试数据， 并实际的执行被测程序； 静态分

3、析则是扫描源程序，从中找出可能导致错误的结构异常，控制流异常及数据流异常。静态分析较动态而言，成本低，容易实现，能覆盖所有路径且不依赖于特定的运行环境。 本文将对现有的静态分析技术展开分析讨论，并在此基础上给出一个新的检测模型。 2. 研究现状研究现状 国内外在软件的安全性分析领域做了大量的研究， 提出了一些可行的静态的安全性分析方法，并且构造了相应的软件安全性分析工具。 目前静态的安全性分析方法可分为2 3 4 5 6 7 8：模型检验，词法分析，语义分析等。 这些检测算法各有侧重，并在现有的检测工具中加以运用，具有一定效果，但其实现的功能，局限性还是比较大的。例如 ITS4 会将所有使用的

4、 strcpy 语句报告，认为不安全。这将直接导致误报率过高, 影响代码审查的效率和积极性；基于模式的安全漏洞并不多，这将直接导致 MOPS 所能维护的规则库有限，并且只能检查某些特定类型的漏洞；BOON 虽然引入了上下文的信息，但是由于没有精确处理控制分支的信息，仅根据数据流走向取并集，仍然存在一定程度的误报，且该方法针对缓冲区溢出和整数溢出，具有一定的局限性。 3. 分析模型分析模型 在这里， 我们考虑将各个现有的成熟的静态代码分析技术结合， 设计一个基于上下文信息关联的检测模型。 1 本课题得到教育部博士学科点专项基金项目（编号：20050013011）的资助。 http:/ - 2 -

5、 3.1 引入引入 我们先来模拟一下人工分析的过程，为提炼模型作准备。 下面以一个使用文件资源的代码段为示例： void fun() 1: File f = fopen(“c:test.txt”, a+); 2: Fclose(f); 以下是人工审查的过程。 首先，若是需要检查文件资源泄露，我们需要定位到文件句柄的打开部分，锁定风险API fopen。其次，记录下该 api 返回的文件句柄,变量 f。以便跟踪该句柄的使用情况。接着，我们发现在行号 2，f 作为参数，被 API fclose 引用，而 fclose 恰好是跟 fopen 对应的 API 操作，表示文件句柄的关闭。故，在此，对于这

6、个文件资源的检测完毕，结论，没有资源泄漏。 根据以上分析，似乎只需要定位关键 API，并跟踪相应的变量使用即可。进一步，考虑下面这段带有条件分支的代码段： Void fun() 1: File f = fopen(“c:test.txt”, a+); 2: if (fRet) 3: return; 4: fclose(f); 若是根据之前的原则分析，依然得出没有错误的结论，然而，可以看到，在行号 3 处，有一个 return 语句，这将直接导致函数退出，显然，在这个退出分支里，打开的文件句柄没有得到关闭，必然造成资源泄漏。 反思一下我们的分析过程，显然，我们忽略了这么一个事实:fopen 的操

7、作是顺次必然执行的，但其对应的 fclose 操作则是受到 if（fRet）语句控制，在其后的 FALSE 控制分支里执行。对于 open 操作，并不是所有的退出分支都有 close 操作,所以导致了文件资源的泄漏。 把对控制条件的处理引入分析: 一 定位关键 API fopen。 二 跟踪返回的句柄，变量 f。 三 定位关键 API fclose 对变量 f 的引用。 四 比较 fopen 与 fclose 是否处在同一逻辑分支。 显然，扩充以后的分析过程，能很好的应对带逻辑分支的代码段。尽管实际工程中的代码远远要复杂得多， 但大多情况不过是各种顺次控制逻辑的组合。 正确的应用这种上下文分析

8、技术，应该能够相对快速的分析代码中的漏洞，并确保一个较低的误报率。 3.2 模型化模型化 在传统静态分析中，风险库是引起各种安全漏洞的 API 的集合，而词法匹配通过对源代码进行扫描，可以对风险 API 定位，这些恰好是我们上下文分析的第一步。在上下文分http:/ - 3 - 析的第二三步中， 我们需要跟踪变量的使用情况， 即对变量的初始定义， 以及其后的再定义，表达式引用，函数调用情况，做链表记录。而在第四步中，要得到程序的分支走向，需要了解的是语句之间的控制依赖关系， 恰恰， 这些工作跟编译器的数据流分析以及控制流分析部分相关，故，我们这里引入一些编译原理的概念和技术，提取上下文信息。

9、构造模型如下： 图 1 安全检测模型 3.3 关键技术关键技术 3.3.1 到达到达_定值分析定值分析 编译原理里，到达定值是这样一个概念： 定值是对x的赋值或读值到x的语句。 称a定值d到达程序点P， 若存在路径从紧跟d的点到达P，且在这条路径上d没有被注销。如果沿着这条路径的某两点间是读值到a或对a的赋值，那么我们注销变量a的那个定值。 我们定义这样一个结构： Struct _VARNODE int iLineNO; int iValue; bool fSet; 在每一个变量出现的地方，生成这么一个节点，其中,iLineNO记录行号信息，若当前语句对于该变量是赋值操作，则把fSet设置为T

10、RUE并把新值记录到iValue中,否则，fSet设置为FALSE,iValue无效。我们把所有该变量的节点添加到一个链表，就可以得到该变量在整个工程的使用情况。这样，我们就可以通过链表查找某行api调用的时候，该变量值域是否在我http:/ - 4 - 们的限制之内。 3.3.2 别名分析别名分析 对同一个存储地址存在多条访问路径， 就会出现别名问题。 访问路径是通过变量及一些运算符生成的表达式。例如*p, i, String varpointer; 对于指针或者引用的定义语句，我们在一张别名表中记录该节点，varorg记录被指向变量名，varpointer记录指针/引用变量名。在其后的指针

11、变量操作中，通过查表，记录到真正指向的变量链表中去。 3.3.3 控制依赖控制依赖 在编译原理里， 控制依赖的概念用于模拟条件分支语句对程序行为的影响， 它是程序控制结构的属性，可以根据控制流图来严格的定义。直观地讲，一个语句w控制依赖于语句u，如果u是一个影响、执行的条件。例如在一个if-then-else结构中，位于条件语句两侧的语句控制依赖于该谓词。 控制依赖图是建立在图论基础上，算法标准，过程复杂。在这里我们抛开其实现细节，仅就结果的应用做讨论。 对于程序段： Void fun() 1：File f = fopen(“c:test.txt”, a+); 2：a: if (fRet) 3

12、： 4： b: return; 5: 6: c: fclose(f); 7: d: return; 8: http:/ - 5 - astartbendc图 2 控制流图 astartbctruetruefalse图 3 控制依赖图 根据控制依赖图，我们可以建立如下表： 表 1 控制依赖表 行号 控制依赖的行号 2 0(true) 4 0(true) 2(true) 6 0(true) 2(false) 7 0(true) 2(false) http:/ - 6 - 显然，根据这张表，我们可以分析出，行号2/4/6都不在同一个分支，行号6/7在同一个分支。 3.4 需要进一步完善的工作需要进一

13、步完善的工作 此上下文分析模型， 是在传统代码检测理论上应用了编译原理中较为成熟的数据流分析和控制流分析技术， 但由于应用环境和目的的复杂程度不同， 其得出信息的准确性仍有待改进。 （1） 赋值判断。模型只对传统的赋值操作进行了处理，例如：a =1; a+; *a = 8 等； 但对于以指针/别名的形式，做为函数参数传入函数内部再进行的数据操作，模型不能识别，只是简单的判断为引用。 （2） 新值计算。数据流分析很大一部份工作是在各个赋值点计算变量的新值。对于传统的表达式 a = (b*6)+10,模型可以很好的处理，但是，涉及到函数调用，若是工程自定义的，需要查询自定义的函数表，切换到该函数的

14、入口语句，进行函数调用计算，其间，涉及大量的参数传递转换操作，必然导致结果的不精确性；若是系统函数调用，如:ch = strstr(strText, “org”),则需要正确的识别该 API的返回信息，模型里只针对几个常用的字符串操作如 strstr/strcat/strcpy 等进行了处理。但在实际的工程中，所调用的库多而复杂，需要去维护/查询/扩充一份系统库 API 列表。 （3） 控制条件理解。控制流分析的处理，是基于语义谓词（if/then/else, break, return等） ，只细化到语句/行号，对于控制条件语义上的理解，完全没有涉及。例如： a: if (sizeof(de

15、s)strlen(org) b: strcpy(des, org); 在此处，对于风险 API strcpy 的调用是安全的，因为 if 语句已经对字符串长度作了判断。然而，我们从控制流分析仅仅得到：语句 b 受控于语句 a，该信息完全不涉及条件语义。目前，模型对于这种情况，作了简化处理：若控制条件中涉及到风险 api 里调用的变量，则认为代码进行了安全判断，该调用安全。显然，这种处理是极为粗糙的，模型需要更加准确合理的去理解控制条件的语义。 4. 总结总结 本文介绍了当前主流的静态代码分析技术， 在分析讨论其优缺点基础上提出了一种新静态代码检测模型。 该模型结合了当前成熟的分析技术， 并借鉴了编译器中数据流和控制流分析的思想，获取上下文关联的数据信息，从而准确地分析代码中存在的安全问题。 http:/ - 7 - 参考文献参考文献 1 Gary McGraw. Software Security: Building Security In. Addison Wesley Professional. January 23, 2006. 2 Chess, B.; McGraw, G. Static analysis for security. Security & Privacy Magazine, IEEE. Volume 2, Iss