本科毕业设计-基于错误注入的组件安全性测试研究

[60]，将所有的不同系统调用按威胁大小确定其权值(见表4.2)。有两种情况只注入单个错误：一种是只有一个系统调用；另一种是在组合错误中只对一个交互点注入错误，其他交互点不注入错误。在只注入单个错误的测试用例中，威胁权值决定了测试用例的执行次序。接下来根据“调用模式”确定注入多个错误的测试用例的次序。首先把系统调用分为读调用和写调用。所谓读调用，就是对环境实体的内容以及相关属性进行查询，并不对其改写，典型的是Read和Access；而写调用则造成实体内容以及相关属性的改变，典型的是Write和Set；但是类似Open这种“打开”调用应从对其操作客体相关的操作序列进行分析，如果序列中只含有诸如Read的读操作，那么这个Open就是读调用，反之则为写调用。对系统调用的读写分类也列在表4.2中。表STYLEREF1\s4.2系统调用威胁权值(1-5)及读写分类根据对己知安全性的分析，易出问题的调用模式是一个读调用紧接一个写调用，因此，将读调用集合中的元素与写调用中的元素进行组合，且威胁权值之和较高的组合优先执行，这就是多个错误的测试用例生成次序。在以上的论述中，一直假设己知所有调用的操作客体，由此得到对调用集的分划。但是在实际的测试过程中，操作客体集在动态环境错误注入之前是未知的。由此，测试前需要运行组件并通过注入点，也就是伪函数得到分划。把这种测试前组件的运行过程称为收集(gleaning)。gleaning过程对调用序列的提取存在几个问题：首先，一般情况下，动态运行组件无法将组件中的调用完全遍历一遍，只能提供其中的一个子集。有两种选择，一是将gleaning提供的调用序列作为事实上的调用，把除此之外组件代码中其他的调用排除在测试用例之外，一是测试用例中仍然保留所有的调用，但是与之相关的测试用例不用上面提出的算法产生，仍旧使用不带启发算法的组合生成。考虑到gleaning过程基本上代表了组件的一般行为gleaning没有遍历的调用在组件的以后运行中不执行的概率还是相当大的，并且排除一些调用可以减少测试用例。测试系统中采取了前一种方案。此外，由于阻塞组件不能立即结束，gleaning过程只能待续设定的一段时间，因此，得到的调用序列也只能是代码中所有调用的子集，对此以相同的方法解决，即测试用例中的调用集以gleaning中出现的为准。以上确定了单个分划子集中的测试用例生成次序，再考虑到一个组件中由于操作客体集的相互链接造成对安全策略的违反的概率较大，给出最终的分划和权值排序(DivisionandSortingbyWeight,简称DSW)测试用例生成算法。算法4.1DSW测试用例生成算法输入：环境错误注入表(如表4.1)，系统调用威胁权值和读写分类表(如表4.2)输出：生成动态环境错误注入的测试用例集T步骤：//第一步：确定操作客体集O以及调用分划Sfori=1tondo通过的参数判定操作的环境实体，记为；forj=1todoif()then；break；endif；endforif()then；；endif；endfor//第二步：生成测试用例集T1和T2，；；fori=1tokdo，其中；通过环境错误注入表找到对应的错误注入集，记为；假设代表无错误，；fori=1tomdoif(符号链接错误)then{符号链接于实体}；{当时，；否则}；endif；；endforendfor//第三步：在T1和T2中进行排序；；，；//取出注入单个错误的测试用例，按威胁权值排序fori=1tondoif(注入错误数==1)then通过系统调用威胁权值和读写分类表找到对应的权值；forj=1tokdo为中第j个测试用例对应的威胁权值；if()then将插入到中第j个位置；break；endif；endforif()then将插入到中第个位置；endif；；；；endif；endfor//注入操作客体集的相互链接错误的测试用例；//取出既包含读调用也包含写调用的测试用例，按调用数量从少到多排好，其中相同调用数量相同的根据威胁权值之和大小排序fori=1tondo通过系统调用威胁权值和读写分类表计算读写调用数量；if()thenforj=1todo为中第j个测试用例的读写调用数量；if()then将插入到中第j个位置；break；endif；if()then分别计算、威胁权值之和，得到和；if()then将插入到中第j个位置；break；else将插入到中第个位置；break；endif；endif；endforif()then将插入到中第个位置；endif；endif；endfor//缺少读调用或者缺少写调用的测试用例不分次序列在最后；根据“基于操作实体的测试用例分划”中的分析，DSW算法产生的测试用例数为。算法首先通过分划减小了测试用例集的规模，然后采用两种相关的算法对其定序，使测试用例按照造成安全策略违反的可能性递减的顺序排列。第一步的时间复杂度为，n为系统调用数；第二步得到测试用例集的大小为：，测试用例集的大小为；第三步为插入排序，在最坏情况下，时间复杂度为第二步得到的测试用例数平方。因此，总的时间复杂度近似为：。违反安全策略监测和环境恢复可以把组件对安全策略的违反分为“局部违反”和“全局违反”。局部违反包括组件崩溃、挂起、潜伏和其他特定于组件功能的异常情况；全局违反是对系统全局安全环境的破坏，比如关键文件的破坏、信息泄漏等。判定这两种违反是个复杂的问题，有时候缺少人工检测就无法判别。因此，测试系统中预先设定一组一般安全规则，将可自动判断的情况包含在内，然后，由分析人员制订依赖于特定组件功能的安全规则，这两种安全规则组成了对组件是否违反安全策略的判据。与通常的组件测试不同，在安全性测试中，完成一个测试用例的执行后，执行环境应该恢复为此测试用例执行前的状态，否则测试用例之间就无可比性，测试结果也缺乏准确性。但是，对系统进行整体备份又显然不现实。这里采用的方法是“按需备份”。即对组件中操作的客体进行备份，不备份系统中其他客体，而且，并不是对所有访问的文件进行备份，而只保存写调用的操作客体，而读调用的操作客体就无需保存。本章小结环境是漏洞攻击者所竭力利用的地方，针对组件环境进行动态的错误注入，是发现组件潜在安全漏洞的一种现实而又有效的方法。本章选择在组件运行之时，对组件运行的环境故意注入人为的错误，在WenliangDuetal.的EAI模型的基础上，提出了一种检测组件安全漏洞的动态环境错误注入方法。首先从整体出发，介绍了动态环境错误注入的概念和所要解决的关键问题。然后围绕所要解决的关键问题，分五个要点进行了详细论述。为了解决实际测试中的“组合爆炸”问题，提出了一种DSW测试用例生成算法，有效地约减了测试用例。在理论的基础上，下面一章将从实践的角度给出本文第三章和本章方法的一种实现。CSTS中错误注入子系统实现在目前的Windows操作系统平台上，基于微软COM(ComponentObjectModel，组件对象模型)标准的组件是最为普遍的组件。随着网络技术的飞速发展，COM到目前已经历了OLE(ObjectLinkingandEmbedding，对象链接和嵌入)、ActiveX技术和.NET平台上.NET组件的发展过程，其间爆发各种各样的COM组件安全漏洞。组件安全测试系统CSTS概述CSTS(ComponentSecurityTestingSystem)是一个组件安全性测试原型系统所实现的自动化测试工具。CSTS是在基于错误注入测试方法和动态监测测试方法的基础上对组件从静态和动态两个级别进行安全性测试。在静态级别上，先分析出组件接口信息，然后对方法参数从参数个数、参数顺序、参数范围和参数类型等方面进行错误注入，注入错误测试用例后再编译执行，观察组件运行状态；在动态级别上，先执行测试驱动，然后对组件所依赖的环境进行错误注入，主要从内存、磁盘文件系统、注册表、进程及网络五个方面进行错误注入，在组件测试驱动执行的同时进行动态监测。图5.1是CSTS系统的总体结构图。CSTS是在WindowsXP平台上用VisualStudio.NET2005C#开发的一个针对COM组件安全性测试的集成测试系统原型，主要包含以下主要功能：(1)对COM组件进行接口分析，得到必要的类型信息；(2)自动生成组件方法级的测试程序，通过进一步生成接口方法测试用例实现接口参数错误注入测试；(3)编译测试程序，生成组件测试驱动；(4)对被驱动运行中的COM组件进行动态环境错误注入测试；(5)动态监测被测试COM组件的运行情况，记录组件异常行为，并写入日志文件；(6)COM组件安全评估与分析。图STYLEREF1\s5.SEQ图表\*ARABIC\s11CSTS系统总体结构图对测试系统的一个重要的要求是自动化，不能实现自动化的测试技术妨碍了软件项目运行周期的流水线推进，而且大大增加了测试成本，因此CSTS设计运行以全自动化或者仅需少量人工操作的方式进行。其中自动化包括：(1)组件自动化测试框架，包括自动生成接口测试用例，自动驱动运行，自动返回测试结果；(2)自动进行接口静态错误注入和环境动态错误注入；(3)自动的COM组件运行时动态监视，监视组件的行为和状态，一旦出现违反安全的异常行为，则证明组件存在安全漏洞；(4)自动安全性测试有效性评估，组件运行完毕自动评估组件的安全性程度和错误注入的有效程度。CSTS功能模块CSTS系统主要功能由五个功能子系统完成：接口分析、测试用例生成、自动编译、错误注入和动态监测。在CSTS系统中进行COM组件安全测试时各模块协作过程如图5.2所示。接口分析对于第三方COM组件，其源代码不可知，测试前必须通过一定的手段得到构图STYLEREF1\s5.SEQ图表\*ARABIC\s12CSTS系统中进行测试时各模块协作过程示意图件的类型信息。CSTS系统中通过分析组件类型信息(TypeInfo)得到组件的接口方法等详细信息。类型库(TypeLibrary)包含COM组件所暴露接口的二进制描述信息。它们包含的信息与IDL(接口定义语言)文件的基本相同。类型库可以是单独的二进制文件(.tlb)，也可以是动态链接库或可执行文件(.dll，.olb，.exe)中的资源。通过分析类型库可以获得以下信息：类型库名称和版本信息；类型信息个数；每个类型信息的接口类型(如CoClass、Interface、Dispatch等)、函数个数及变量个数；函数名、返回值类型、标志位、调用类型(如function、get、put等)、参数个数、可选参数个数、参数名、参数类型和参数方向。以上分析得到的信息均同时存储在预先定义的XML格式文件中。测试用例生成根据接口分析模块产生的XML文件，生成测试用例模块所需要的测试程序(CS测试文件)。主要实现步骤是：使用XPath技术读取接口信息XML文件；根据XML文件，利用CodeDom技术生成测试程序文件；根据组件安全需求说明得到组件接口方法中的初始参数。自动编译自动编译模块主要完成把待测试COM组件、测试用例文件和相关程序集(dll格式)自动编译成动态链接库文件(dll格式)，供驱动程序调用。实现功能：通过读取配置文件config.xml获取指定位置的COM组件和COMTLB文件，完成COM组件注册；选择测试用例程序(程序类型为cs格式)及相关程序集(dll格式)，编译生成可执行的动态链接库文件，用于驱动器调用执行。错误注入错误注入模块主要完成从静态和动态两个级别上对待测COM组件进行错误注入，以测试待测COM组件在运行的过程中是否出现违反安全的异常行为。实现功能：接口参数错误注入和动态环境错误注入(下文详述)。动态监测动态监测模块主要利用Windows操作系统中调试API技术获得对测试驱动的控制，从而对其运行状态进行监测。实现的主要功能有：监测组件函数运行时的堆栈值（函数的输入参数）；在函数运行结束时的堆栈值（函数的输出参数）；CPU寄存器的值（函数返回值）。基本原理：在获取组件函数的入口地址后，在函数入口上设置断点；当程序调用了设置断点的函数时便会产生调试中断事件，进一步可暂停目标程序的运行，读取目标程序内存；最终获得目标程序内存中希望得到的信息。测试系统CSTS根据状态监测日志中的组件状态信息及其相关异常信息识别组件是否存在安全漏洞。错误注入子系统设计系统总体流程在CSTS中，根据COM组件的特点，系统采用静态接口参数错误注入和动态环境错误注入实施错误注入，以测试COM组件的安全性。其总体错误注入流程如图5.3所示：图STYLEREF1\s5.SEQ图表\*ARABIC\s13CSTS错误注入流程首先，通过COM接口分析自动得到COM组件对象、接口、方法及方法参数等必要的错误注入测试信息，然后对组件方法进行静态的“接口错误注入”，自动生成TestFixture(包含测试用例的测试文件)，将测试文件和必要的条件引用进行自动编译链接，生成可执行的TestFixture(测试驱动可以识别的DLL文件)。接着，驱动组件运行起来，在组件运行的过程当中，同时对组件的运行环境进行动态的“环境错误注入”，并监视组件的行为是否出现异常。最后，对测试的结果进行分析，判定是否出现安全漏洞。其中，静态接口错误注入和动态接口错误注入是两个相互独立的过程，可以将静态接口错误注入和动态环境错误注入分开测试，也可以贯穿于一个测试流程当中，并且可以对静态接口错误注入生成的测试用例手工修改或添加新的测试用例。系统结构和功能错误注入子系统是CSTS的一个重要组成部分。按照错误注入的总体流程，CSTS错误注入子系统的结构设计如图5.4所示。图STYLEREF1\s5.SEQ图表\*ARABIC\s14错误注入子系统结构图根据系统功能要求错误注入子系统包含以下两个功能模块：(1)接口参数错误注入对接口错误注入，基于的是现有的Ballista方法，即对接口方法的参数进行错误注入，以参数类型为核心预先构造无效的、畸形的异常参数案例库，对接口方法的参数类型、参数顺序、参数个数、输入值、输出值进行“轰炸”，触发组件内部的安全漏洞通过接口爆发出来。(2)动态环境错误注入对运行时的组件，从内存、磁盘系统、进程、网络及注册信息等相关环境进行错误注入。在组件被驱动运行时错误注入模块根据错误注入的类型在进程中对组件和操作系统交互的相应API进行拦截。采用的技术是用预先定义的伪DLL替换系统DLL。根据环境错误注入测试要求，预先编写一些同名的伪DLL用于替换原来的系统DLL。根据错误注入类型，对于不需要拦截的API函数直接把参数传递给系统DLL对应的API函数处理并返回结果。对需要拦截的API，则在伪DLL中添加拦截代码进行拦截，同时注入错误。系统实现关键技术实现组件动态环境错误注入，关键是要对选定的环境错误注入点，即组件和操作系统交互的相应系统API调用进行截获。这里针对COM组件，需要对Win32API系统调用进行截获。实施Win32API系统调用截获的过程主要分两个方面：根据CSTS中选择的错误注入类型，查找到需要截获的系统API，对组件驱动进程中所调用的这些API进行拦截，将其替换为指向中间伪函数；为防止将环境错误也注入到驱动进程中，在伪函数中需要对调用该API的对象进行判断，如果是待测COM组件则进行错误注入，否则调用原系统API。图STYLEREF1\s5.SEQ图表\*ARABIC\s15Win32API截获原理图5.5描述了Win32API截获原理。其原理可以描述如下：在驱动进程中，需要调用三个系统API函数S1、S2、S3，并假定S1、S3是一次环境错误注入中要截获的系统API。编一个伪DLL包含两个伪函数forgeS1和forgeS3(与S1、S3有相同的原型)。其中，驱动进程的IAT(ImportAddressTable，导入地址表)保存了其导入系统函数S1、S2、S3的地址。通过修改驱动进程中IAT表中S1、S3的入口地址使其分别指向伪函数forgeS1和forgeS3，这样每当驱动进程调用S1、S3时，实际调用的却是伪函数forgeS1和forgeS3，这样就实现了对S1、S3的拦截。在伪函数forgeS1、forgeS3中进一步对调用者进行判断，因为驱动进程中除了待测COM组件调用系统函数S1、S3外有可能还有其他调用者，如果调用者是待测COM组件，则实施环境错误注入，否则转向正常调用系统函数S1和S3。这样就实现了COM组件对系统API调用的截获。当需要恢复COM组件对系统函数S1和S3的调用时，只需将驱动进程IAT中指向伪函数forgeS1和forgeS3的指针替换回指向S1和S3的指针即可。1)通过改变导入地址表拦截API调用在寻找针对API函数的调用点时，必须知道驱动进程空间中内容的排列方式。在Win32操作系统中，进程空间中的内容及其排列方式由与该进程对应的EXE文件决定。EXE文件不但包含了进程的可执行代码和数据，同时也详细地记录了进程所引用到的所有DLL和外部函数的信息。所以，可以根据EXE文件的格式来寻找针对目标函数的调用点。Win32操作系统中的EXE文件和DLL文件都属于PE(PortableExecutable)格式。PE文件格式定义了若干个数据结构，分别用于保存文件的代码、数据和输入输出函数等信息，利用这些结构可以很容易地对PE文件进行操作(如图5.6所示)。PE文件的主体是若干个文件节，其中有一个称为.idata的节，专门用于保存EXE文件从DLL中引入的所有外部函数的信息，包括调用点的信息，所以，可以根据这个节的格式，并结合API函数的调用方式，来寻找并替换针对目标函数的调用点。图STYLEREF1\s5.SEQ图表\*ARABIC\s16PE文件结构当程序调用某外部函数时，它并非是从调用处直接跳转到函数入口处，而是先统一跳转到一个共同的中间点，那里保存着一行CALLDWORDPTR[XXXXXXXX]形式的指令，XXXXXXXX就是IAT中与调用函数相对应的函数指针。因此，寻找针对API函数的调用点时，首先根据API函数所在DLL的名称，从.idata节的结构体数组中找到与该DLL对应的结构体，然后再根据API函数的名称，可以在与该DLL对应的IAT中找到与API函数对应的函数指针。因为所有对API函数的调用都将根据该处的指针来跳转到API函数，所以，修改该指针，将其改变为指向伪函数的指针，便实现了用伪函数替换API函数。在恢复时，执行同样的步骤，将指向伪函数的指针替换回指向API函数的指针即可。另外，需要改写的

.idata

节不一定都是可写的，可以调用系统函数VirtualProtect(…)

来实现。2)利用“钩子”技术注入伪DLLWin32操作系统实行了“进程地址空间分离”的机制，每个进程有自己独立的地址空间，所以CSTS主进程不能直接访问驱动进程空间中的内容，不能直接在驱动进程空间中寻找针对系统API函数的调用点，因此必须设法突破进程边界，将执行寻找API函数调用点的代码和伪函数注入到驱动进程的空间内。有多种打破进程边界的方法，比较简单的方法是使用钩子(Hook)。钩子是Win32操作系统中用来拦截窗体消息的一项技术，分为两种类型：线程钩子和全局钩子。前者只拦截某个具体窗体的消息，后者则能拦截所有正在运行程序的窗体消息。钩子通过安装来运行。安装钩子时需要提供一个钩子回调函数，而且该函数必须位于一个DLL中，当钩子安装好后，系统就会将该DLL加载到窗体所属进程的空间内。每次钩子拦截到窗体消息时，回调函数都会首先被系统调用，以预处理消息，直至钩子被卸载。钩子被卸载后，DLL也将被从窗体进程的空间内卸载。这样，可以利用钩子来打破进程边界：将执行截获的代码和伪函数与钩子回调函数放在同一个伪DLL中，然后针对驱动进程的窗体安装一个线程钩子，钩子运行后，伪DLL便会被强制注入到驱动进程的空间内。当需要从驱动进程空间内撤离这些代码时，只需将钩子卸载掉即可。3)根据返回地址确定调用对象在错误注入之前，关键是需要判定调用者是否是待测的COM组件。确定API函数的调用者，可以通过API函数调用的返回地址进行判断。图STYLEREF1\s5.SEQ图表\*ARABIC\s17函数调用栈空间在如图5.7所示的函数调用栈空间中，用如下内联汇编可获取调用API函数的返回地址。DWORD*retAddress;__asm{Movecx,[ebp+4]/*4是4个byte，32位机器，就是指针下一个，取到存returnaddress的块的地址*/MovretAddress,ecx/*从寄存器中取出放入一个指针里面，用指针记录这个地址*/}DWORDadd=*retAddress;/*add中就是返回地址的值*/通过该地址，可以借助操作系统系统提供的一个函数virturalquery(…)得到该地址所在虚拟地址空间块的信息。在这个结构体信息中有一个值，是调用模块的基址值也即句柄值，通过句柄值就可知道该模块的名称和其他信息。于是，通过模块的名称就可知道调用该API函数是否是待测COM组件。本章小结本章针对目前普遍使用的COM组件研制自动化安全性测试工具并实现其中的核心部分之一——错误注入子系统。首先对组件安全测试系统(CSTS)的总体框架和功能模块进行了简要的介绍，然后详细给出了错误注入子系统的总体流程、结构和功能设计，最后对系统实现关键技术——API截获技术进行了充分的论述。COM组件测试及效果评估上一章已经介绍了CSTS中错误注入子系统的设计和实现，为了进一步检验错误注入子系统在测试COM组件安全漏洞中的实际效果，本章选择两个第三方COM组件作为测试实例进行错误注入前后的对比分析，达到验证接口参数错误注入和动态环境错误注入有效性的测试目的。COM组件测试测试环境在配置Intel处理器并安装WindowsXPSP2中文版操作系统和.NETFramework2.0版本的软硬件平台上，对CSTS中错误注入子系统的有效性进行测试。测试实例为了证明接口参数错误注入的有效性，以一个有漏洞的第三方COM组件vuln.dll作为测试样本(考虑到第三方COM组件一般接口和方法数较多，样本组件中仅有针对性设计了一个接口和五个成员方法，这五个成员方法中有几个方法是存在安全漏洞的，但事先并不知)，分两个方面去证明接口错误注入的有效性：在没有接口错误注入之前，考察能否测试出组件安全漏洞；在接口参数错误注入之后，考察能否检测出组件安全漏洞并能给出漏洞原因的分析结论。除了能证明接口参数错误注入在揭露已知安全漏洞方面的能力，接口错误注入还要能够检测出事先未知是否有漏洞，即新的、未曾公布的COM组件安全漏洞，接下来给出这样的测试案例。由于目前公布的COM组件安全漏洞尚无环境扰动方面的实例，为了证明动态环境错误注入的有效性，以一个第三方COM组件GomWeb3.dll作为测试实例，对在没有环境错误注入和环境错误注入后COM组件安全测试的结果进行对照，根据动态环境错误注入所发现的新的潜在安全漏洞表明动态环境错误注入的有效性。测试过程1)测试第三方COM组件vuln.dll在不进行接口错误注入的前提下，使用CSTS测试vuln.dll有如下几个步骤：(1)新建项目，选择待测COM组件vuln.dll；(2)COM组件接口分析；(3)自动生成测试脚本文件；(4)手动添加或修改测试用例；(5)编译链接；(6)启动测试驱动程序；(7)开始动态监视；(8)执行测试；(9)测试结果查看分析。经过COM组件接口分析，发现vuln.dll有一个组件对象Server，Server中有一个接口Iserver，Iserver中有五个成员方法：Method1()、Method2()、Method3()、Method4()、HeapCorruption()，其原型如下所示：dispinterfaceIserver{properties:methods:longMethod1([in]BSTRsPath);longMethod2([in]longlin);longMethod3([in]VARIANTvin);longMethod4([in]BSTRsPath,[in]BSTRmsg);longHeapCorruption([in]BSTRstrIn,[in]longbufSize);}针对这五个成员方法，可手动输入简单测试用例如下：namespacevulntest{usingSystem;usingSystem.Collections.Generic;usingSystem.Text;usingSystem.Runtime.InteropServices;usingCOMTest;[TestFixture]publicclassserver{privateVULNLib.serverClassmyserverClass=newVULNLib.serverClass();[SetUp]publicvoidSetUp(){}[Test]publicvoidIserverMethod1(){stringsPath="test";myserverClass.Method1(sPath);}[Test]publicvoidIserverMethod2(){myserverClass.Method2(0);}[Test]publicvoidIserverMethod3(){stringvin="test";myserverClass.Method3(vin);}[Test]publicvoidIserverMethod4(){stringsPath="test";stringmsg="test";myserverClass.Method4(sPath,msg);}[Test]publicvoidIserverHeapCorruption(){stringstrIn="test";myserverClass.HeapCorruption(strIn,0);}}}图6.1是在未进行接口参数错误注入的测试结果。图STYLEREF1\s6.1未接口参数错误注入的测试结果使用CSTS进行接口参数错误注入测试vuln.dll的步骤如下：(1)新建项目，选择待测COM组件vuln.dll；(2)COM组件接口分析；(3)选择“接口错误注入”自动生成测试用例；(5)编译链接；(6)启动测试驱动程序；(7)开始动态监视；(8)执行测试；(9)测试结果查看分析。针对以上五个方法原型，接口参数错误注入自动生成如下测试用例：namespacevulnInterfaceFaultInjection{usingSystem;usingSystem.Collections.Generic;usingSystem.Text;usingSystem.Runtime.InteropServices;usingCOMTest;[TestFixture]publicclassserver{privateVULNLib.serverClassmyserverClass=newVULNLib.serverClass();[SetUp]publicvoidSetUp(){}[TearDown]publicvoidTearDown(){}[Test]publicvoidIserverMethod1(){stringsPath=newstring('A',500);longresult=myserverClass.Method1(sPath);}[Test]publicvoidIserverMethod2(){longresult=myserverClass.Method2(2147483647);}[Test]publicvoidIserverMethod3(){stringvin=newstring('A',500);longresult=myserverClass.Method3(vin);}[Test]publicvoidIserverMethod4(){stringsPath=newstring('A',500);stringmsg=newstring('A',500);longresult=myserverClass.Method4(sPath,msg);}[Test]publicvoidIserverHeapCorruption(){stringstrIn=newstring('A',500);longresult=myserverClass.HeapCorruption(strIn,2147483647);}}}图6.2是在进行接口参数错误注入后的测试结果。图STYLEREF1\s6.2接口参数错误注入后的测试结果2）测试第三方COM组件GomWeb3.dll在不进行动态环境错误注入下测试GomWeb3.dll和在不进行接口错误注入的前提下测试vuln.dll的步骤一样，其测试结果如图6.3所示。图STYLEREF1\s6.3未动态环境错误注入的测试结果使用CSTS进行动态环境错误注入测试GomWeb3.dll的步骤如下：(1)新建项目，选择待测COM组件GomWeb3.dll；(2)GomWeb3.dll接口分析；(3)自动生成测试脚本文件；(4)编译链接；(5)启动测试驱动程序；(6)开始动态监视；(7)选择要注入的“环境错误”，如内存不足和注册表崩溃(如图6.4所示)；(8)执行测试。动态环境错误注入后的测试结果如图6.5、图6.7所示。图STYLEREF1\s6.4选择注入的环境错误图STYLEREF1\s6.5环境错误注入后的测试结果测试效果评估一个首要的安全需求是阻止一个不可信的组件访问主机上任意地址和资源，如“存储越界访问”或“非法访问异常”。如果在测试过程中出现“存储越界访问”，则表明待测组件存在安全漏洞。接口参数错误注入的有效性从图6.1可以看到在没有接口参数错误注入之前，手动输入的12个测试用例全部执行成功，但在接口参数错误注入后，第三方COM组件vuln.dll出现“存储越界访问”异常(如图6.2所示)，从而表明vuln.dll存在安全漏洞。进一步反复对vuln.dll进行“接口参数错误注入”，生成不同的测试用例，通过查看参数在输入何值时导致异常，最终得出vuln.dll漏洞原因结论：(1)Method1()仅有一个字符串类型参数sPath，在输入超长字符串的时候，产生缓冲区溢出漏洞，因此漏洞原因在于sPath没有进行有效的参数长度检查；(2)Method2()、Method3()经检测无安全漏洞；(3)Method4()的二个参数sPath和msg均是字符串类型，但只有第二个存在缓冲区溢出漏洞，因此漏洞原因在于msg没有进行有效的参数长度检查，未经验证就输入到缓冲区导致安全漏洞；(4)HeapCorruption()的两个参数strIn和bufSize，一个是字符串，另一个是长整型，对第一个参数输入超长字符串导致缓冲区溢出，对第二个参数输入大整数时造成整数溢出。通过以上对第三方COM组件vuln.dll的安全测试，可知：在没有接口错误注入之前，不能测试出组件安全漏洞，而在接口参数错误注入之后，能检测出组件安全漏洞并能给出漏洞原因的分析结论。因此，证明了接口参数错误注入在揭露已知安全漏洞方面的有效性。除了能完全检查出现今已知的或已公布的COM组件安全漏洞，接口参数错误注入还能够检测出事先未知是否有漏洞和未曾公布的COM组件安全漏洞。图6.6就是一个通过接口参数错误注入检测出的未曾在网上公布的新的安全漏洞。该漏洞源自腾讯QQ2006珊瑚虫版CoralAssist.dll组件(版本15)，其中的一个方法Excute()的三个字符型参数，均未对输入值进行长度检查，导致缓冲区溢出漏洞。图STYLEREF1\s6.6CoralAssist.dll组件漏洞另外，暴风影音Ⅱ的一个COM组件mps.dll(版本2.07.06.15)经接口参数错误注入也发现了未曾公布的安全漏洞，该组件中的URL属性输入超长字符串时，出现存储访问越界异常，另一个函数advancedOpen()也暴露出缓冲区溢出漏洞。综上所述，接口参数错误注入不仅在揭露已知安全漏洞方面有效，而且在揭露未知安全漏洞方面也同样具有一定的有效性，因而证明了接口错误注入的有效性。动态环境错误注入的有效性从图6.3可以看到在没有动态环境错误注入之前，手动输入的78个测试用例全部执行成功，但在动态环境错误注入后，78个测试用例失败2个，同时第三方COM组件GomWeb3.dll在执行过程中出现“存储越界访问”异常(如图6.7)，表明GomWeb3.dll存在安全漏洞。在以上测试GomWeb3.dll过程中，可知是由于注入了“环境错误”——内存不足和注册表崩溃而导致GomWeb3.dll执行出现异常，通过监视日志查看GomWeb3.dll在执行过程中调用系统API的情况，发现GomWeb3.dll在执行接口方法OpenURL()对应的测试用例时调用了系统函数LocalAlloc()，即本地内存分配函数，当选择注入“内存不足”环境错误时，返回一个“ERROR_NOT_ENOUGH_MEMORY”的模图STYLEREF1\s6.7环境错误注入后出现“存储越界访问”异常拟错误，而GomWeb3.dll没有正确处理该错误，忽视了返回值的应有判断，导致在没有分配的内存空间上越界访问，所以出现“存储越界访问”异常。综上，通过在没有环境错误注入和环境错误注入后GomWeb3.dll安全测试的结果进行对比分析，动态环境错误注入不仅能发现新的安全漏洞，并且能定位到安全漏洞产生的具体来源，从而证明了动态环境错误注入的有效性。本章小结本章对错误注入子系统进行了测试，通过选取两个典型的测试实例进行系统测试验证了系统的功能。测试表明针对第三方COM组件运用所设计与实现的错误注入子系统完成了对组件静态的接口参数错误注入和动态的环境错误注入功能，通过错误注入子系统能有效地触发组件内部的安全漏洞，并能结合动态监视得出组件漏洞原因的结论。这说明错误注入子系统的功能设计正确，实现有效。结束语本文工作总结随着组件特别是第三方组件的使用，大大提高了软件开发的效率，但同时也增加了软件可靠性和安全性的风险。随着互联网的发展，这种风险越来越突出。作为保障组件安全的可靠手段——组件安全性测试成为重要的研究内容。然而由于其理论和技术的难度，组件安全性测试研究尚未取得实质的进展。本文即在此背景下对组件安全性测试的理论与技术进行研究，提出了一种基于错误注入技术的SDFI组件安全性测试方法，并在实践上设计和开发了一个COM组件安全自动化错误注入测试系统，测试结果表明SDFI在组件安全性测试中具有一定的实用性和有效性。本文的主要工作及创新总结如下：1)对错误注入技术概念、历史以及利用错误注入技术进行安全性测试的方法进行了深入的研究和探讨，并针对组件、尤其是第三方组件，提出一种基于错误注入的SDFI组件安全性测试方法；2)通过对组件安全性测试基本概念、研究内容和难点的研究，在安全漏洞分类学研究的基础之上，给出了一种FIM组件安全错误注入测试模型；3)根据FIM针对组件运行前和运行时两个不同的时机，分别提出了测试组件安全漏洞的基于Ballista的接口参数错误注入方法和基于EAI模型的动态环境错误注入方法，并给出了相应的EEC和DSW测试用例约减算法；4)在理论研究的基础上，针对目前普遍使用的COM组件，设计和实现了基于Win32API截获技术的CSTS组件安全自动化错误注入子系统；5)选取第三方COM组件作为测试实例进行错误注入前后的对比分析，测试结果表明通过错误注入子系统不仅能有效地揭露已知的安全漏洞，还能触发组件未知的安全漏洞，从而验证了SDFI组件安全性测试方法的有效性。后续工作展望由于时间关系和作者水平有限，课题研究中还存在一些不足，一些工作还需要进一步的完善和深入。作者认为还需要在下面这些方面做更深层次的研究工作：1)深化接口参数错误注入方法的研究在本文基于Ballista的接口参数错误注入方法中，通过预先针对不同参数类型构建各种各样的异常元素，测试用例就是这些不同异常元素的组合，但并没有提供对不同类型的异常元素进行结构化的设计，下一步的工作就是如何使测试用例的构造更为系统化，使测试用例更有针对性。2)改进错误注入测试用例生成算法在本文提出的接口参数错误注入和动态环境错误注入方法中，测试用例生成算法仍然需要改进，现有的算法在处理较复杂的组件时产生的测试用例集合还是过大，并且错误注入测试用例的有效性还需要进一步提高。今后工作重点可围绕这一方面进行深入研究。3)完善和增强CSTS与错误注入子系统的功能目前的CSTS工具只能测试基于COM标准的简单组件，对参数约束、有状态的情况以及需要搭建运行环境的复杂组件仍然需要手工操作。如何实现一个更通用的、针对任何Windows平台的组件安全性测试工具也将是下一阶段工作的方向之一。另外，错误注入子系统中动态环境错误注入功能需要提高Win32API截获的稳定性和效率，这方面也有待解决。硕士阶段的生活短暂而充实，在师长的关心和帮助下，作者在专业知识方面取得了不小的进步，各方面的能力也有了提高。作者十分清楚自己存在的缺点和不足，在今后的工作和学习中还要不断努力提高自己的综合素质。致谢硕士阶段的学习即将结束，两年的学习生活紧张而又愉快。论文是我这一阶段学习工作情况的总结。在此谨向所有关心、帮助、支持过我的老师、同学、朋友和亲人致以最诚挚的感谢！首先要感谢我的导师徐丽萍副教授，本文是在她的孜孜不倦的教诲和无微不至的关怀下完成的。这里谨向徐老师表示最诚挚的谢意与敬意！我还要特别感谢敬爱的卢炎生教授：卢老师深厚的理论功底、渊博的学识、儒雅的学术风范和兢兢业业、精益求精的工作态度给我留下了深刻的印象，深深地感染和激励着我，也将永远鞭策着我不断进取！卢老师正直无私的品格，豁达的胸襟，乐观积极地人生态度展现了学者的思想境界和人格魅力，为我树立了做人的楷模，使我终生难忘！感谢谢晓东老师在课题研究上给我悉心的帮助和指导。谢老师严谨的学术态度、忘我的工作精神和耐心细致的言传身教不断激励着我，在此特别感谢谢老师对我的鼓励，帮助和信任感谢殷贤亮副教授、杨茂林老师、赵小松老师、潘鹏老师、吴海老师、江胜老师、瞿彬彬老师等各位老师在学习和生活中对我的指导和帮助，从你们身上我学到了丰富的知识和宝贵的经验。感谢陈锦富、游亮、黄晋博士，同课题组的温贤鑫、王平、张超、倪铭同学，在实验室的学习生活中我们朝夕相处，与他们在学术上的交流，给了我很多有益的启示，使我受益颇多。感谢师兄，感谢实验室所有的师兄师姐和师弟师妹们，感谢你们和我一起度过快乐的时光！感谢我的父母。一直以来，他们都无私地为我贡献着，风风雨雨陪伴我走了过来。回首这两年走过的路，回顾过去的点点滴滴，觉得万分地感动。我要向他们深深地鞠一躬！最后感谢所有关心、爱护和帮助过我的亲人和朋友！PAGE参考文献GPour.Component-BasedsoftwareDevelopmentApproach:NewOpportunitiesandChallenges[C].In:ProcofTechnologyofObject-OrientedLanguages,1998:375-383.张勇，基于规格说明的组件安全性测试技术研究与实现，中国人民解放军信息工程大学硕士学位论文，2005.12。毛澄映，卢炎生，构件软件测试技术研究进展，计算机研究与发展，2006年08期：1375-1382。ClarkJAPradhanDK.FaultInjection:AMethodforValidatingComputer-SystemDependability.IEEEComputer,1995,28(6):47-56.AnupK.Ghosh,TomO'Connor&GaryMcGraw,AnAutomatedApproachforIdentifyingPotentialVulnerabilitiesinSoftware,ReliableSoftwareTechnologiesCorporation,1998.邹涛，张翠，许博义，基于故障注入的软件安全性测试方法研究，全国抗恶劣环境计算机第十五届学术年会，2005：26-29

。AnupK.Ghosh&GaryMcGraw,AnApproachforCertifyingSecurityinSoftwareComponents,ReliableSoftwareTechnologies,1998.PanelModerator:JimReynolds,Teknowledge,HowUsefulIsSoftwareFaultInjectionforEvaluatingtheSecurityofCOTSProducts,IEEESoftware,1998.NimalNissanke,ComponentSecurity–IssuesandanApproach,Proceedingsofthe29thAnnualInternationalComputerSoftwareandApplicationsConference(COMPSAC’05),IEEE,2005.K.Md.Khan,J.HanandY.Zheng,"CharacterisingUserDataProtectionofSoftwareComponents,"inSoftwareEngineeringConference,2000Australian,IEEEsoftware,Canberra,ACT,Australia,2000,pp.3-11.K.Md.Khan,J.Han,"AssessingSecurityPropertiesofSoftwareComponents:ASoftwareEngineer'sPerspective,"inProceedingsofthe2006AustralianSoftwareEngineeringConference(ASWEC),IEEE,2006,pp.199-210.J.Han,K.Md.Khan,"ASecurityCharacterisationFrameworkforTrustworthyComponentBasedSoftwareSystem,"inProceedingsofthe27thAnnualInternationalComputerSoftwareandApplicationsConference(COMPSAC),IEEE,pp.164-169,2003.J.Han,Y.Zheng,"SecurityCharacterisationandIntegrityAssuranceforComponent-BasedSoftware,"IEEEsoftware,pp.61-66,2000.A.Bertolino,A.Polini,"AFrameworkforComponentDeploymentTesting,"inthe25thInternationalConferenceonSoftwareEngineering(ICSE),IEEEComputerSociety,pp.221–231,2003.J.M.Haddox,G.M.KapfhammerandC.C.Michael,"AnApproachforUnderstandingandTestingThirdPartySoftwareComponents,"inProceedingsAnnualReliabilityandMaintainabilitySymposium,IEEE,Seattle,WA,USA,pp.293-299,2002.MartinS¨ußkrautChristofFetzer,RobustnessandSecurityHardeningofCOTSSoftwareLibraries,37thAnnualIEEE/IFIPInternationalConferenceonDependableSystemsandNetworks,2007.Hsueh,M.C.,Tsai,T.,Iyer,R.:FaultInjectionTechniquesandTools.In:IEEEComputer,pp.75-82,1997.J.V.Carreira,D.Costa,andS.J.G,"FaultInjectionSpot-ChecksComputerSystemDependability",IEEESpectrum,pp.50-55,1999.J.Carrara,H.Madeira,J.GabrielSilva.Xception:ATechniquefortheExperimentalEvaluationofDependabilityinModernComputers.IEEETrans.onSoftwareEngineering,1998,24(2):125-136.H.Mills.Onthestatisticalvalidationofcomputerprograms.TechnicalReportFSC-726015,IBMFederalSystemsDivision,1972.BiemanJM,DreilingerD,LINLi-jun.Usingfaultinjectiontoincreasesoftwaretestcoverage[A].SoftwareReliabilityEngineeringProceedingsSeventhInternationalSymposium[C].NewYork:IEEEComputerSocietyPress,pp.166-174,1996.J.Voas,"FaultInjectionfortheMasses,"Computer,vol.30,pp.129-130,1997.R.Barbosa,N.Siliva,J.Durãe,HMadeira,VerificationandValidationof(RealTime)COTSProductsusingFaultInjectionTechniques,2007.W.DuandA.P.Mathur.VulnerabilityTestingofSoftwareSystemUsingFaultInjection.TechnicalReport,COAST,PurdueUniversity,WestLafayette,IN,US,1998.JMVoas&AnupK.Ghosh.Softwarefaultinjectionforsurvivability.DARPAInformationSurvivabilityConferenceandExposition,P338-346,1999.CowanCPuCMaierDetal.StackguardAutomaticAdaptiveDetectionandPreventionofBuffer-overflowAttacks.InProceedingsofthe7thUSENIXSecuritySymposium,pages:63-78,1998.11.MillerB.PKoskiDLeeC.Petal.FuzzRevistedARe-examinationoftheReliabilityofUnixUtilitiesandServices.Technicalreport,UniversityofWisconsin,ComputerSciencesDept,1995.JoãoDurãe,HenriqueMadeira,DefinitionofSoftwareFaultEmulationOperators:aFieldDataStudy.TheInternationalConferenceonDependableSystemsandNetworks,2003.朱鸿宇，谢余强，刘瑰，基于故障注入发现缓冲区溢出漏洞的研究，微计算机应用，2005年06期26卷：676-678。R.Moraes,R.Barbosa,J.Durães,N.Mendes,E.Martins,H.Madeira,Injectionoffaultsatcomponentinterfacesandinsidethecomponentcodearetheyequivalent,ProceedingsoftheSixthEuropeanDependableComputingConference,IEEE,2006.B.P.Miller,L.Fredriksen,andB.So,"AnEmpiricalStudyoftheReliabilityofUNIXUtilities",CommunicationsoftheACM33,12(December1990).Alsoappears(inGermantranslation)as"FataleFehlertractigkeit:EineEmpirischeStudiezurZuverlassigkeitvonUNIX-Utilities",iX,March1991.NathanP.Kropp,PhilipJ.Koopman,DanielP.Siewiorek,AutomatedRobustnessTestingofOff-the-ShelfSoftwareComponent,CarnegieMellonUniversity,1998.Koopman,P.Siewiorek,D.DeVale,K.DeVale,J.Fernsler,K.Guttendorf,D.Kropp,N.Pan,J.Shelton,C.Shi,Y.“BallistaProject:COTSSoftwareRobustnessTesting”,CarnegieMellonUniversity,2003.Martins,E.Rubira,C.M.F.LemeN.G.M.“Jaca:Areflectivefaultinjectiontoolbasedonpatterns”Procofthe2002InternConferenceonDependableSystems&Networks,pp.483-487,WashingtonD.C.USA,23-267,2002.李明，高勇，李祥和，基于语法的软件安全检测，信息安全与通信保密，2006年08期：86-87，91。PeteBroadwell,NaveenSastry,JonathanTraupman.FIGProject-FaultInjectioninglibc(FIG),RecoveryOrientedComputing(ROC)-UCB,December10,2001.JamesA.Whittaker.ICSE–RuntimeFaultInjection.Toappear.单国栋，连一峰，环境错误注入测试机制，计算机工程，2004年第30卷19期：113-114，182。\o"王航"王航，\o"戴英侠"戴英侠，单国栋，连一峰，软件系统安全脆弱性测试技术，\o"计算机科学"计算机科学，2002年29卷08期：134-136。C.Szyperski.ComponentSoftware-BeyondObjectOrientedProgramming[M].AddisonWesley,1997.Moraes,R.andMartins,E.“AnArchitecture-basedStr