一种基于安全状态跟踪检查的漏洞静态检测方法研究与实施.doc

计算机学报2009年5期 一种基于安全状态跟踪检查的漏洞静态检测方法研究与实施 本课题得到国家自然科学基金项目（60703102, 60873213）、北京市自然科学基金项目（4082018）和国家863 项目（2007AA01Z414）的资助。梁彬，男，1973年生，博士，副教授，主要研究方向为信息安全与系统软件，Email: liangb. 侯看看，女，1986年生，硕士研究生，主要研究方向为静态分析。石文昌，男，1964年生，博士，教授，博士生导师，主要研究方向为信息安全、可信计算与系统软件。梁朝晖，女，1968年生，博士，讲师，主要研究方向为信息安全、网络通信。梁彬 侯看看 石文昌 梁朝晖（中国人民大学信息学院 北京100872）（数据工程与知识工程教育部重点试验室 北京100872）摘 要：现有的采用基于源代码分析的漏洞静态检测方法中存在的主要问题是误报率和漏报率较高。主要原因之一是缺乏对数据合法性检查与非可信数据源等程序安全相关元素的精确有效的识别分析。本文提出了一种基于数据安全状态跟踪和检查的安全漏洞静态检测方法。该方法对漏洞状态机模型的状态空间进行了扩展，使用对应多个安全相关属性的向量标识变量安全状态，细化了状态转换的粒度以提供更为精确的程序安全行为识别；在漏洞状态机中引入了对合法性检查的识别，有效降低了误报的发生；建立了系统化的非可信数据鉴别方法，可防止由于遗漏非可信数据源而产生的漏报。基于此方法的原型系统的检测实验表明：本文方法能够有效检测出软件系统中存在的缓冲区溢出等安全漏洞，误报率明显降低，并能避免现有主流静态检测方法中存在的一些严重漏报。关键词：漏洞检测；静态分析；状态机；漏报；误报中图分类号：TP309Research and Enforcement of a Static Vulnerabilities Detection MethodBased on Security State Tracing and CheckingLIANG Bin Hou Kan-Kan SHI Wen-Chang LIANG Zhao-Hui(School of Information, Renming University of China, Beijing 100872)(MOE Key Laboratory of Data Engineering and Knowledge Engineering, Beijing 100872)Abstract The main problem of existing static vulnerability detection methods based source code analysis is their high false positive and false negative. One main reason is lack of accurate and effective identification and analysis of security-related program elements, e.g. data validation checking, tainted data source, etc. A static vulnerability detection method based on data security state tracing and checking is proposed. In this method, the state space of state machine model is extended; the security state of a variable is identified by a vector that may correspond to multiple security-related properties rather than by a single property; fine-grained state transition is provided to support accurate recognition of program security-related behaviors; the recognition of validation checking is introduced in vulnerability state machine to reduce false positives; and a systematic discrimination mechanism for untrustworthy data is constructed to prevent false negatives result from neglecting untrustworthy data sources. The experimental results of a prototype system show that this method can effectively detect buffer overflow and other types vulnerabilities in software systems, and with obviously lower false positive than existing mainstream static detection methods and avoid some serious false negative of these methods.Keywords vulnerabilities detection, static analysis, state machine, false negative, false positive1 引言大多数信息安全事件的根源在于计算机软件系统中存在有安全漏洞（Vulnerability）1。要杜绝这类安全事件，最根本的办法在于在软件发布前检测出安全漏洞并修正。为了提高漏洞检测的效率，安全界对自动化的漏洞检测技术进行了研究，主要有动态分析（Dynamic Analysis）和静态分析（Static Analysis）两类。动态检测工具使用较容易2，且确实能够发现一些安全漏洞，但测试用例对程序逻辑的覆盖率问题限制了动态检测工具的发掘能力，难于发现隐藏较深的安全漏洞。静态漏洞分析技术主要通过对系统代码进行程序分析（Program Analysis）以发现各种安全漏洞3，例如缓冲区溢出、非法指针引用、竞争条件等等。与动态分析相比，静态分析技术能够支持更为有效的深度漏洞检测。漏报（False Negative）和误报（False Positive）是各种安全漏洞检测技术所要共同面对的问题。近年来，漏洞静态检测技术已经取得了很大的进展，研究人员已经提出和实现了一些漏洞静态检测方法和工具，目前已在操作系统等复杂系统的漏洞检测中得以应用4。但仍然存在着误报率和漏报率较高的问题，影响着静态漏洞检测方法进一步推广应用。这与检测模型和安全相关程序特征的识别有着密切的关系。首先，现有静态检测方法采用单一的性质标识对程序数据安全性质进行描述，这种一元的描述机制难以进行细粒度的数据状态分析和精确跟踪分析多种平行发展的数据安全相关性质，不能很好地全面覆盖安全漏洞的激发条件。直接导致的一个严重问题是缺乏对非可信数据合法性检查的有效识别，从而产生大量的误报。目前的检测方法仅仅集中于跟踪分析数据的可信性，一元的安全性质标识往往被完全用于描述数据的可信性，无法精确跟踪对非可信数据所实施的合法性检查，混淆了未经合法性检查的和已经过检查的非可信数据。现实中，几乎所有的软件系统都要处理各种各样的非可信数据，而大部分非可信数据在引用前都经过了相应的合法性检查，消除了其导致危险操作的可能性。因此，这种混淆的后果会将大量安全的非可信数据操作识别为安全漏洞，将导致大量的安全程序片段被错误地检测为含有安全漏洞，从而产生大量的误报。例如，根据文献5数据，Johnson等人使用CQUAL系统对Linux内核代码进行的用户态/内核态指针引用漏洞检测，由于缺乏对合法性检查的有效识别，误报率在95%以上。如此高的误报率需要投入大量的资源进行后期人工分析，大大增加了漏洞静态检测技术推广应用的难度。其次，虽然个别的漏洞静态检测方法实现了部分的合法性检查识别，但对合法性检查是否有效缺乏必要的深入分析，未能区分出实现上存在缺陷的无效的合法性检查，从而产生漏报。以斯坦福Engler等人研发的静态漏洞检测系统MC所采用的方法为例6，MC中用于检测内存操作长度越界漏洞的Range Checker中引入了对非可信数据的上/下界检查的识别，由于模型表示空间的限制，其仅仅检测长度参数是否经过了相应的算术比较，而并不关心参与比较的上/下界值的类型。而入侵者能利用一个负值的整数绕开与常量或有符号上界值进行的上界比较，触发安全漏洞。在现实世界中，最近几年此类安全漏洞已经大量出现在各种平台系统中，例如Linux内核中的蓝牙设备驱动有符号缓冲区索引安全漏洞 Linux Kernel Bluetooth Signed Buffer Index Vulnerability. http:/cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0750。由于缺乏必要的检查有效性识别，MC未能检测出此漏洞。此外，现有静态检测方法对于数据可信性的鉴别也缺乏清晰的概念模型，在实际应用中容易遗漏一些较隐蔽的非可信数据源，导致对部分非可信数据跟踪分析的缺失而产生漏报。以MC所采用的方法为例，在其对Linux内核的漏洞检测中，遗漏了内核对用户文件的装载解析这一非可信数据源，导致了对可执行文件解析所引发的安全漏洞的误报。针对以上问题，本文提出了一种对程序数据安全状态进行跟踪检查的漏洞静态检测方法。在此方法中，使用有限状态机模型描述程序数据安全性质的变化，对描述数据安全状态的状态空间进行了扩展，采用了多元的状态描述机制，使用一个对应多个安全相关属性的布尔向量标识变量安全状态，更为清晰地反映了变量安全性质的变化，细化了状态转换的粒度以提供更为精确的程序特征识别。在此基础上，利用多元的安全状态设置在跟踪分析数据可信性的同时引入了对合法性检查及其有效性的识别，有效降低了由此引起的误报和漏报的发生。此外，在本文方法中还引入了可信边界与可信边界入口的概念，以可信边界的界定为线索建立了系统化的非可信数据鉴别方法，防止了由于遗漏非可信数据源而产生的漏报。为验证方法的有效性，作者基于编译技术实现了一个可实际运行的原型检测系统DELTA（DEtect vuLnerability with sTatic Analysis）。使用DELTA对Linux内核代码的漏洞检测实验表明，本文方法能够有效检测出系统中存在的安全漏洞，并能避免其他主流静态检测工具中存在的漏报和误报，为提高软件质量及安全性提供了有效可行的方法及工具。本文第2节给出了一种基于程序安全状态的安全漏洞检测方法；第3节描述了DELTA的设计及实现；第4节描述了对Linux操作系统内核源代码的静态检测实验，展示了方法的应用效果；第5节介绍相关工作并进行了分析比较；最后是全文的总结。2 检测方法2.1 概述本文检测方法的基本思想是对程序状态的跟踪和检查。如图1所示，在本文中将使用基于有限状态机模型的漏洞状态机描述程序变量安全状态的转换规则，针对待检测漏洞设置相应的漏洞状态机规定相关数据的状态转换；并对程序各可能执行路径进行静态遍历并识别当前操作，对当前操作所涉及的程序变量根据状态机赋予其对应的安全状态；在安全相关操作处设置检查点（Checkpoint），以检测操作数据是否具有期望的安全状态，若出现与期望安全状态不符的情况，则表示发现了一个可能的安全漏洞。安全检查点安全状态检查安全状态转换漏洞状态机变量安全状态程序执行路径安全漏洞信息图1 检测方法示意图以拷贝超长数据所导致的缓冲区溢出漏洞为例，当使用内存拷贝函数memcpy根据一个未经上界检查的用户输入的操作长度参数复制超长的数据至目标缓冲区时，将发生缓冲区溢出。此时，安全漏洞的相关要素为：安全相关操作内存拷贝函数；操作数据状态用户输入的（非可信的）、未经上界检查的操作长度参数。内存拷贝操作将为一个安全检查点，检测系统所期望的操作长度参数为一个可信数据或经过上界检查的非可信数据。当一个用户输入的数据进入系统处理流程时，将被标识为非可信数据。若经过了有效的上界检查，其状态中将加入通过上界检查的标识；否则，在作为内存拷贝操作长度参数时，检测系统将认为其不具有期望的安全状态，会引发一个缓冲区溢出漏洞。2.2 漏洞状态机模型在传统漏洞静态检查中所采用的状态机模型中，数据的安全状态使用单个属性值标识，如MC6和XGCC7等。在本文中，为精确跟踪多种平行发展的数据安全性质（主要为数据的可信性和合法性检查状态），对漏洞状态机的状态空间进行了扩展。首先给出以下模型元素： SRP：变量安全相关属性集，SRP包含各种细化后的安全漏洞相关变量特征，例如数据来源、已经经过的合法性检查（可能为多个）、指针释放与否等。不失一般性，设SRP集合元素个数为n，属性被赋予1至n的编号； STO：安全状态转换操作集STO，STO包含各种导致变量安全相关属性发生变化的操作，例如赋值、拷贝、数据比较检查等； opp: STO P (1, 2 , n)，安全状态转换操作到SRP编号集的幂集上的一个映射，标识STO中的元素所对应的相关SRP属性编号集； opv: STO × 1, 2 , n true, false, 标识一个STO操作对相关的某个SRP属性的状态设置，为true表明此STO操作导致变量具备了相关的属性或被执行了相关操作。在漏洞状态机中，将使用一个对应SRP集元素的布尔向量描述变量安全状态。基于有限状态机模型，一个漏洞状态机为以下一个五元组：VM = <S, , f, s0, Z>漏洞状态机各元素的定义如下： S：安全状态集，为对应SRP集的n维布尔向量集，即：S = true, falsen = (s1, s2, , sn)÷ si = true 或 false其中，分量si对应编号为i的SRP属性； ：状态机控制字符集，为状态机对应安全漏洞的安全相关操作，即 = STO； f : S × S，状态转换函数，表示在当前状态下实施一个安全相关操作后的后续安全状态。对于一个安全状态s = (s1, s2, , sn)及一个STO操作op，设f (s, op) = s = (s1, s2, , sn)，其中：si = si, 当 i Ï opp (op)；si = opv (op, i), 当 i Î opp (op) s0 (false, false, , false)，初始状态，其所有元素为false，表示变量未具备任何安全相关特性或被执行了相关操作； Z：终止状态集，在漏洞状态机中此集为空，即 Z Ø。在漏洞状态机中，安全状态由对应SRP集元素的布尔向量表示，标识程序变量是否具备相关安全属性或被执行了什么操作。SRP集的设置由具体的目标系统与待检测的漏洞类型决定，主要由3部分构成：（1）变量值是否为一非可信的数据，即此数据是否有可能被恶意用户所控制对于软件系统而言，其存在的每一个安全相关编程错误不一定能最终导致对系统安全的危害，只有当攻击者构造的恶意数据能够触及到有缺陷的代码时，方可能导致实际的安全威胁。否则，其仅仅是一个难以被触发的编程错误而非一个安全漏洞。因此，对变量可信性的标识是通过变量状态跟踪以检测安全漏洞的重要基础。在实际检测中，主要将对非可信数据进行跟踪，安全状态布尔向量中将设置一个分量标识变量是否源自一个非可信数据。（2）变量通过了的合法性检查实际系统中，在引用外部非可信数据前，往往需要进行合法性检查，例如对外部指定的内存操作长度进行上界检查。在静态检测中对合法性检查的识别较为复杂，对于不同的待检测漏洞，所涉及的合法性检测不同。即使是同一漏洞类型，各系统中实现的合法性检测的静态表现形式也存在差异。此外，合法性检查还可由多个步骤组成，如首先检查操作长度变量的符号，再检查其上界。如图2所示，为了能较准确地识别合法性检查，拟细化合法性检查的识别粒度，将合法性检查分解成一序列相关的子步骤进行识别。在SRP中，将针对具体的漏洞相关的合法性检查构成，设置与之对应的多个变量安全相关属性，用于标识目标变量所经过的合法性检查步骤。而且，每个步骤可细化为对应着一个检测引擎可单步识别的基本语法单位，从而保证了精确识别。安全状态布尔向量中的相应分量用于标识此变量是否通过了相应的合法性检测步骤。此外，合法性检查各阶段的检查结果被单独记录在变量的安全状态中，各阶段的检查结果互不覆盖，在检查点上再对变量是否具有期望的安全状态进行检查。从而不必前摄性地规定合法性检查各步骤的排列次序，符合实际系统程序设计的规律。如此，可将合法性检查的识别与变量状态的跟踪统一到漏洞状态机中，既提高了合法性检查的识别准确性，又保证了漏洞检测机制的简洁高效。true/false安全状态合法性检查步骤合法性检查true/falsetrue/false图2 合法性检查细化识别如若使用一元的安全状态描述机制，必将需要在较大的粒度上对合法性检查进行分析判断，这需要相应的程序模式归纳。而涉及合法性检查的各种可能的构成形式及排列次序很难归纳为相对固定的表示序列，这必将导致对合法性检查程序模式的部分缺失。例如，有符号整数的有效上界检查就可能包含多种构成形式。每种形式都可能包含多个次序可以任意变换的步骤，如通过判断整数是否非负和是否小于一个常量上界来进行检查。多元的安全状态描述机制能够较自然地容纳对这种不定次序的多步骤检查的识别。而在采用一元安全状态描述机制的MC中6，整数上界检查被作为一个整体进行识别判断，此判断只能在一个不全面的上界检查特征归纳基础上进行，不可避免地会降低识别分析的精度。对Linux内核蓝牙设备驱动安全漏洞的漏报就是一个直接的后果。（3）变量的操作实施状态释放后指针引用、多次释放等漏洞类型还涉及到对目标变量操作实施的流程，特别是对指针型变量的操作流程。为此，在SRP中还设置了相应的元素标识对目标变量已实施的操作，例如针对释放后指针引用类型漏洞，设置了标识指针已被释放的状态元素。从以上分析描述可见，对安全状态空间进行的多元化扩展并不是数量上简单的增加，而是为了更好地符合程序设计自然规律、提高检测精确度所进行的必然选择。2.3 非可信数据鉴别漏洞状态机的核心是状态转换的处理，即状态转换函数f的确定。变量在声明后，其初始安全状态为s0，其后续状态根据其上所实施的相关操作（中元素）确定。当变量被直接或间接赋予一个可能被恶意用户所控制的数值时，将设置其安全状态中的相关分量，标识其为一非可信的数据。数据可信性的确定与具体目标系统的结构和数据处理机制密切相关，基于软件系统的一般结构特征，引入以下概念支持非可信数据的鉴别：定义一：可信边界（Trusted Boundary）是目标系统不受外界影响的数据生成处理边界，在可信边界内生成的数据不受外部操作的影响。定义二：可信边界入口（Entry Point）是外部数据进入可信边界的通道。界定可信边界最重要的目的在于鉴别非可信数据，即通过明确外部数据输入途径来确定哪些数据源自非可信的外部世界。可信边界上的所有内外数据通道构成了可信边界入口。在界定了可信边界后，以其为线索可确定可信边界入口。现代软件系统，特别是系统软件，一般将其所提供的底层服务集成在一个相对独立的核心组件中，通过接口对外提供服务。以操作系统为例，其内核通过系统调用接口为应用程序提供了底层的计算服务，内核中的数据生成与操作不受用户态应用程序控制。这种共性的体系结构为可信边界的界定提供了良好的基础，可结合待检测漏洞的特性对目标系统体系结构进行安全性分析，界定具体的可信边界。可信边界入口不仅仅是系统服务的调用接口，还包括所有可能的外部数据输入机制，例如操作系统内核协议栈中对远程网络数据包的接收等。可信边界入口将被作为非可信数据源。若目标系统中的可信边界入口集为EP，其应属于安全状态转换操作集STO，即EP Í STO。不失一般性，假设标识非可信数据的SRP属性编号为1，即安全状态向量中的第1个分量用于标识数据是否可信。对于变量v，对应的漏洞状态机状态转换函数fv为："ep EP，fv (s, ep) = (true, false, . , false)其中s为v的当前安全状态，s S。需要注意的是，当变量v通过可信边界入口接收了外部数据后，其状态向量中的除第1个分量外的其它分量都被初始化为false。这是因为当变量被非可信数据感染后，其以前所通过的合法性检查等安全状态设置需要重新计算。除了在可信边界入口处标识非可信数据外，还需要考虑变量间的安全状态传播，其核心是非可信数据的转播。变量间的状态转播主要包含以下2种情况：（1）赋值传播当一变量作为一赋值表达式的左值（LValue）时，其安全状态将由表达式右值（RValue）表达式安全状态决定。对于各种形式的右值表达式S，其安全状态sstate (S)按以下情形计算： 当S为单个变量x时，sstate (S) = state(x)， 其中state (x)为变量x的安全状态； 当S为单个常量时，sstate (S) = s0； 当S为对函数fun的调用时，sstate (S) = state(return (fun)，其中return (fun)为函数fun当前调用实例的返回值； 当S由多个子表达式组成，如S1和S2，当first_component(sstate(S1) = true 或first_component(sstate(S2) = true时，sstate (S) = (true, false, . , false)，否则 sstate (S) = s0，其中first_component (S)为状态向量S的第1个分量。在赋值传递中，考虑到安全漏洞检测的特殊性，对于由多个子表达式组成的右值表达式，本方法采取一种较为激进的方法，表达式安全状态将只考虑各子表达式是否会引入非可信的数据，而忽略其它SRP属性的传播。（2）内存拷贝传播除了直接赋值以外，内存的拷贝操作也会引起安全状态的传播，源内存区域数据的安全状态将目的内存区域数据的安全状态。以内存拷贝函数memcpy为例，进行memcpy (d, s, len)调用后，指针d指向的数据的安全状态将等于指针s指向的数据的安全状态。2.4 数据合法性检查为提高识别的准确性，合法性检查被分解成一序列相关的子步骤进行识别，当非可信变量通过了子步骤相应的判断后，变量安全状态向量中将相应的分量设置为true，标识其通过了对应的合法性检查步骤。对非可信数据的合法性检查主要有两种方式：逻辑运算判断，例如检查是否大于、小于、等于或不等于某个值；合法性检查例程，通过调用系统中内建的合法性检测例程进行判断。在实际实施中，将针对具体的目标系统，总结各种漏洞类型相关的合法性检查模式，细化为一系列对非可信数据的检查步骤，对应着相应的状态设置，最终基于状态机模型实现合法性检查的识别与变量的状态转换。下面以操作长度越界引发的内存非法操作漏洞为例进行具体的解释。相应漏洞状态机的SRP集设置如下：SRP = tainted, unsinged upper-bound checked, singed upper-bound checked, non-negative以上SRP集由4个元素组成，分别对应数据是否非可信、通过了无符号上界检查、通过了有符号上界检查、通过了非负判断等，对应编号为1至4。在以上SRP集下，可能的安全状态向量共有16个（24），完全的状态转换图较为复杂。为了描述方便，图3给出了一个简化的状态转换示意图。一个整型变量的初始状态为s0， 表示其未被非可信数据污染并且未经过任何安全检查；当此变量被赋予了一个非可信值后状态转换到 (true, false, false, false)，表示其受到非可信数据污染；在处于非可信状态的变量经过了上界检查后，其状态转换到 (true, true, false, false) 或 (true, false, true, false)，表示一个非可信整数通过了相应的无符号或带符号上界检查；若此变量为一有符号整型，还可能对其进行非负判断，状态将转换至 (true, false, true, true)；在任何状态下，若变量受到非可信数据污染，其状态都将转换到 (true, false, false, false)，类似的，若变量被赋予了一个可信值，其状态变为s0。上界检查与整型变量的符号类型和密切相关。对于一个非可信的无符号整型变量，如果通过了一个与其它数据进行的上界比较判断，则其状态转换为(true, true, true/false, true/false)；对于非可信的有符号的整型变量，需根据与之进行比较的数据类型决定其状态转换： 通过了与常量进行的上界比较判断，则状态转换为(true, true/false, true, true/false)； 通过了与有符号变量进行的上界比较判断，则状态转换为(true, true/false, true, true/false)； 通过了与无符号变量进行的上界比较判断，则状态转换为(true, true, true/false, true/false)；此外，如果有符号整型变量为非负整数（通过了一个非负判断，例如判断是否不小于0），可以将其作为一个无符号整型变量对待。因此，需要在安全状态向量中加以标识，通过非负判断的非可信变量状态将转换为(true, true/false, true/false, true)。S0(true, false, false, false)(true, true, false, false)(true, false, true, true)(true, false, true, false)图3漏洞状态机状态转换图在合法性检查的识别中进行这样的区分有着非常重要的现实意义。这是因为在进行带符号的比较判断时，一个负值一定小于正值。而在C/C+语言中，内存操作函数的长度参数和数组索引将被作为无符号整型处理。一个被赋予负值的有符号整型变量能通过使用带符号比较判断的上界合法性检查，但当其被作为内存操作函数的长度实参或数组索引时，将被解释为一个非常大的无符号正值从而导致一个缓冲区溢出或非法地址访问漏洞。由于历史原因，程序员往往忽视了这种有符号变量和无符号变量混用的危险，导致此类安全漏洞层出不穷。由此，在内存操作（例如memcpy）和数组下标等检查点上，相关变量的合法安全状态应为以下之一： s0； (true, true, true/false, true/false)，标识其通过了一个无符号上界检查； (true, false, true, true)，当变量仅仅通过了一个带符号上界检查时，期望其为一非负值。否则将表明发现了一个可能的安全漏洞，例如将状态为(true, false, true, false)的变量作为memcpy函数的长度实参。图3中仅仅给出了一部分可能的安全状态间的一个不完全的状态转换图，所有16个可能状态间的转换远比图3中所示的情况复杂。特别是SRP集还可能引入新的元素以识别更多的合法性检查，例如下界检查。这将导致更为复杂的状态转换。若在检查系统中直接记录并实现所有的状态转换规则，必定会导致实现及效率上问题，并会大大影响系统的可扩展性。但由于大部分状态转换仅仅改变安全状态向量中的一个分量，状态转换规则可被大大简化。如表1所示，对于以上状态机，其所有合法性检查相关的状态转换规则可被简化为4条。2.3节中涉及到的其余状态转换规则也可同理简化。表1合法性检查相关状态转换规则前状态STO后状态(s1, s2, s3, s4)变量为无符号数时：任意上界比较(s1, true, s3, s4)变量为有符号数时：常量上界比较、有符号上界比较(s1, s2, true, s4)变量为有符号数时：无符号上界比较(s1, true, s3, s4)非负判断(s1, s2, s3, true)2.5 检查点在使用漏洞状态机对程序数据安全状态进行跟踪的基础上，对安全漏洞检测的实施将通过在一些安全攸关的操作点上对当前操作所涉及的数据变量的安全状态进行检查来进行。一些在本文实验中所采用的检查点及在Linux系统中的部分实例如表2所示。表2 检查点检查点相关参数状态检查相关安全漏洞实例（Linux内核）内存分配、拷贝，设置等操作操作长度、操作地址操作长度和操作地址若为非可信数据，必须经过上界检查或访问合法性检查；缓冲区溢出、信息泄漏、非法内存访问等kmalloc、kmem_cache_alloc、memcpy、copy_from_user、copy_to_user、 memset、.数组索引索引非可信的索引数值应经过上界检查非法内存访问、非法函数调用等数组元素引用，如arrayx指针引用操作指针指针未被释放过释放后指针引用指针引用，如*p 、p->q 、循环循环次数非可信的索引数值应经过上界检查死循环导致的拒绝服务需要特别指出的是，在Linux内核中，copy_from_user等函数既是可信边界的入口，又是安全漏洞检测的检查点。3 原型系统为检验以上检测方法的效能，作者实现了一个针对系统软件的静态检测系统原型DELTA，能支持对C/C+语言开发实际的目标系统的漏洞检测实验。3.1 系统结构源码代码解析静态分析引擎漏洞模式漏洞上下文信息预处理图4 DELTA系统结构如图4所示，DELTA系统首先对待检测的系统源代码进行预处理和代码解析，并形成中间代码形式输出至一个静态分析引擎。引擎将在漏洞模式（状态机）支持下进行安全漏洞检测，主要机制为通过遍历代码中的执行路径驱动漏洞状态机运行来跟踪变量的安全状态，并在检查点上将相关变量的安全状态与期望安全状态进行比对。若发现可能的安全漏洞将输出相应的漏洞上下文信息。DELTA系统基于编译技术实现： 预处理器与解析器预处理器与解析器相当于编译器的前端（Front-end），负责将原始源代码文件转换成检测引擎能够识别处理的形式。原始的程序源代码文件往往引用了其他一些说明性的文件，如C/C+语言中的头文件。这些文件通过语言的包含机制相互连接起来。预处理工具将模拟真实编译器编译链接过程，识别根文件，以根文件为基础将相关的源文件整合在一起，形成完整的分析单位。解析器将对预处理过的文件进行词法分析与语法分析，并生成面向静态分析的中间代码。DELTA中的预处理器与解析器基于GCC 编译器的前端实现，利用了GCC中的C/C+语言标准的lex、yacc描述脚本为基础生成相应的词法与语法分析器。在语法分析结束后，将根据所获得的语法元素生成静态单赋值（Static Single Assignment，SSA）形式的中间代码8，中间代码将以基本块（Basic Block）的形式组织在一起。 静态检测引擎静态检测引擎将首先根据源代码函数间的调用图（Call Graph，CG）确定根函数（Root Function），并构建控制流图（Control Flow Graph，CFG）。以根函数为起始点，用CFG驱动漏洞状态机运行，模拟源码文件的实际操作，遍历其相应中间代码的各个可能的逻辑执行路径。在状态机运行过程中，引擎将根据当前操作和各个变量的安全状态决定其的后继状态。若当前程序点为一个漏洞检查点时，引擎还将对相关变量的当前安全状态进行检查。若出现不符合当前检查点对变量的安全要求的情况，则表示发现了一个可能的安全漏洞，引擎将向用户输出相关漏洞上下文信息（主要包括漏洞位置、数据传播路径等）。在很多情况下，安全漏洞的产生跨越多个函数过程，甚至是多个源文件。为了能有效检测出这类安全漏洞，分析引擎应能实施过程间（Inter-procedural Analysis）和文件间分析（Inter-file Analysis）。过程间分析需要对函数调用进行跟踪分析。若当前语句为一个函数调用时，将跟踪被调用函数（Callee）的中间代码；在分析完毕后，返回到调用点继续分析调用函数（Caller）。文件间分析的基础是过程间分析，即当调用函数与被调用函数位于不同源文件时，应能跨越源文件进行过程间分析。文件间分析需要逐个解析待分析的源文件，然后联立多个文件的解析结果并构建跨文件的全局CG，确定根函数后进行过程间分析。在DELTA中，每一种漏洞类型模式对应着一个漏洞状态机。检测引擎中可同时运行多个漏洞状态机，以同时检测多种安全漏洞。在实际应用中，可根据资源情况选择装载待检测的漏洞状态机。DELTA系统中的漏洞状态机以检查器（Checker）链接库形式实现。在静态检测引擎中设置了钩子（Hook）函数，涵盖状态转换、状态传播和检查点等程序节点，检测引擎将在这些点上调用已装载的检查器中的实施函数。3.2 系统配置为验证上述方法及原型的有效性，作者选择了Linux内核作为实验对象，使用DELTA对其进行了漏洞检测实验。作为检测的基础，首先需要确定Linux系统可信边界和可信边界入口。根据Linux操作系统内核的结构特点，完全源于内核中的数据的安全性不会被用户态操作所影响，可信边界可依据系统内核边界界定。但需要特别注意的是，虽然基于内核良好的结构化可较容易地确定可信边界，但Linux内核中外部数据输入途径并不都是直接明晰的，需要依据可信边界深入进行分析归纳。通过分析，Linux内核相应的可信边界入口类型如表3所示：表3 Linux内核可信边界入口可信边界入口引入的非可信数据实例系统调用接口用户态程序提供的调用参数sys_open、sys_read、sys_write、sys_mknod、sys_ioctll等内核态/用户态数据交换例程拷贝自用户态内存的数据copy_from_user、get_user等网络包读取源自网络协议栈传入的远程网络包数据sk_buff->data等可执行程序等用户文件装载解析载入内核的用户可构造的文件数据linux_binprm->buf等在上表中所包括的可信边界入口中，文件的装载解析最容易被遗漏而导致漏报。事实上，Linux内核在装载可执行程序等文件时，会从这些文件中引入影响内核操作的数据。例如，装载执行一个恶意构造的可执行二进制文件，会间接地影响内核task_struct等关键数据结构中某些域值，对这些域值的不适当处理可能会导致安全漏洞。针对