大学毕业论文-—com组件栈缓冲区溢出漏洞检测技术研究.doc

硕士学位论文COM组件栈缓冲区溢出漏洞检测技术研究学位申请人： 学科专业： 计算机软件与理论指导教师： 答辩日期： IIA Dissertation Submitted to Huazhong University of Science andTechnology for the Degree of Master of EngineeringThe Research on stack buffer overflow detection of COM componentCandidate: Zhang Chao Major: Computer Software and TheorySupervisor: Prof. Lu YanshengHuazhong University of Science and TechnologyWuhan 430074, P.R.C.January, 2007独创性声明本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除文中已经标明引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到，本声明的法律结果由本人承担。 学位论文作者签名： 日期： 年 月 日学位论文版权使用授权书本学位论文作者完全了解学校有关保留、使用学位论文的规定，即：学校有权保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权华中科技大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。本论文属于 保密 ，在_年解密后适用本授权书。不保密。（请在以上方框内打“”）学位论文作者签名： 指导教师签名： 日期： 年 月 日 日期： 年 月 日华中科技大学硕士学位论文摘 要为了解决软件复用，缩短软件开发时间，降低维护成本和实现程序动态升级，软件设计领域产生了组件化程序设计结构，并且日益成为发展趋势。微软的COM组件对象模型是当今比较成熟的软件组件模型之一，被广泛应用于Windows操作系统和应用程序中。随着COM组件技术的大量使用，COM组件暴露出越来越多的安全问题，其中，缓冲区溢出安全问题占了很大比例。缓冲区溢出漏洞一直是安全漏洞最常见的一种形式。缓冲区溢出问题主要出现在C/C+这类非类型安全语言中，而在新一代的编程语言，例如Java、C#中不存在。一个重要的原因就是C/C+允许通过指针进行间接内存访问但没有缓冲区边界检查和提供了大量对缓冲区可能存在不安全操作的库函数，在Windows操作系统中也存在类似的函数。因此，如果能采用有效的手段对COM组件的缓冲区溢出漏洞进行检测，将能极大地提高组件软件的安全性。根据COM组件多数情况下源代码未可知的测试特点，基于COM组件的二进制代码实现对其可能存在的栈缓冲区溢出漏洞的检测。检测方法是将检测缓冲区溢出问题转化为整数范围分析问题。建立适用COM组件的危险函数库，在汇编代码中识别危险函数的调用位置，然后根据危险函数参数的类型通过扫描识别不同的缓冲区，将声明的缓冲区大小和使用的缓冲区大小等价为整数范围，依据制定的缓冲区溢出标准检测溢出漏洞。根据COM组件使用虚表定位函数的结构特点，实现了COM组件中用户函数的精确定位；同时利用IDC脚本语言提取了COM组件中的函数依赖关系图。基于以上工作，实现了一个COM组件栈缓冲区溢出漏洞检测原型系统。关键词：缓冲区溢出，静态分析，二进制代码，COM组件，危险函数AbstractIn order to solve the problem of software reuse, shorten software developing period, reduce maintenance cost and realize software automatic updating, component software design is put forward and has become an inevitable developmental trend. Microsofts Component Object Model (COM) is a relatively mature one of software component models, which is widely used in Windows operating system and application programs. Along with the prevalence of COM, more and more security problems are exposed, of which buffer overflow constitutes a high proportion.Buffer overflow has been one of the commonest forms of security holes. It mainly exists in the non type-safe languages, such as C and C+. However, new generation languages, such as Java and C#, do not have this problem. One of the most important reasons is that C allow indirect memory access by pointer without boundary check and provide many unsafe functions which may cause buffer overflow. Meanwhile, there are such functions in Windows operating system. Therefore, if effective means can be adopted to detect buffer overflow, security of component software will be greatly enhanced.Buffer overflow detection based on binary code is thoroughly studied in this thesis because in most cases the source code of COM is unknown. A detection algorithm is proposed by modeling the buffer overflow problem and transform it to ranges comparison of integers. First, establish an unsafe function library of COM and use it to distinguish unsafe function calls in assembly code. Second, according to types of arguments passed to unsafe functions, different buffers are distinguished. Third, obtain ranges of integers based on the size of declared buffers and allocated ones. Last, use buffer overflow detection criterion made by this thesis to detect buffer overflow. COM uses virtual table to locate functions. According to this structural characteristics, this thesis realise accurate positioning of user functions and extract their dependence relations by means of IDC script language. Based on the work mentioned above, a prototype system that can detch stack buffer overflow of COM is realised.Keywords: buffer overflow,static analysis, binary code, COM component,unsafe function目 录摘 要IABSTRACTII1 绪 论1.1 课题背景(1)1.2 国内外概况(2)1.3 论文主要研究工作(4)1.4 论文结构(5)2 COM组件及栈缓冲区溢出漏洞检测方法基础2.1 COM组件(6)2.2 缓冲区溢出原理(8)2.3 栈缓冲区溢出检测技术(11)2.4 小结(19)3 COM组件栈缓冲区溢出漏洞检测技术3.1 函数的识别(21)3.2 参数的识别(25)3.3 函数的返回值(25)3.4 变量的识别(27)3.5 COM组件危险函数库建立(30)3.6 小结(34)4 COM组件栈缓冲区溢出漏洞检测系统设计与实现4.1 模块结构和功能(35)4.2 主要数据结构(36)4.3 函数定位模块实现(37)4.4 栈溢出静态分析模块实现(38)4.5 结果输出模块实现(47)4.6 与CSTS的接口(49)4.7 小结(50)5 实验与测试5.1 实验目的(51)5.2 实验环境(51)5.3 测试用例(52)5.4 测试结果(53)6 总结与展望6.1 工作总结(59)6.2 工作展望(60)致谢(61)参考文献(62)附录 攻读学位期间参与的科研项目(67)691 绪 论1.1 课题背景继面向对象的软件设计方法之后，基于组件的软件设计方法正在逐渐成为新的趋势1。按照组件化程序设计的思想，复杂的应用程序被设计成一些小的、功能单一的组件模块，这些模块可以运行在同一机器上，也可以运行在不同的机器上，每台机器的运行环境可以不同，甚至可以是不同的操作系统。为了实现这样的应用软件，组件需要一些细致的规范，只有组件程序遵守这些共同的规范，组件软件才能正常运行。目前流行的组件规范有三种，它们是OMG(Object Management Group)提出的CORBA(Common Object Request Breaker Architecture)；微软提出的COM(Component Object Model)；还有SUN公司提出的EJB(Enterprise Java Bean)。Cai2给出了三种规范的详细比较。微软的COM组件对象模型是当今比较成熟的软件组件规范之一，被广泛应用于Windows操作系统和应用程序中。在分布式计算、Internet网络、三层体系结构开发以及音视频处理等前沿领域，COM组件技术正在被大量使用。COM组件在受到广泛应用的同时，自身的安全问题也日益暴露。其中，缓冲区溢出安全问题占了很大的比例。在安全日益被人们所关注的今天，缓冲区溢出毫无疑问是最大的安全威胁之一。1988年，Internet上的第一例蠕虫(Morris)攻击，就是利用Vax和Sun机器fingerd中的缓冲区溢出漏洞。SANS评选出的2005年威胁最大的20个漏洞中，有8个跟缓冲区溢出有关。国内绿盟科技根据安全漏洞的严重程度、影响范围等因素综合评出2006年度的十大安全漏洞，缓冲区溢出漏洞占4个。绿盟科技在2006年发布CVE漏洞8个，而缓冲区溢出漏洞就占了5个。根据CERT的统计数据，近几年与缓冲区溢出有关的安全事件在50%以上。经过十几年的发展，缓冲区溢出已经成为一种成熟和最有效的黑客攻击手段。并且在接下来的许多年里，情况仍然会是这样。随着COM组件的广泛应用，COM组件中暴露的缓冲区溢出的安全问题的数量也是逐年上升。因此检测COM组件的缓冲区溢出漏洞具有十分重要的意义。COM组件多数情况下源代码不可知，目前常用的测试方法是黑盒测试。按照经验和一般规律设计大量测试用例，以期望触发组件的漏洞和异常。这种方法在某些时候会起到较好的效果，但效率太低，而且对测试人员的经验和技术水平要求很高。为了改进已有的COM组件测试方法，提高对COM组件安全漏洞的检测，本论文研究并实现了COM组件栈缓冲区溢出漏洞检测原型系统。同时，对COM组件进行静态分析获取其结构信息和安全漏洞信息是实验室正在研发的针对COM组件的安全漏洞自动检测工具的需要。所以本论文研发的原型系统可以很好与实验室研发的自动检测工具结合，以完善该工具的效率和功能。1.2 国内外概况软构件技术提供了一种较面向对象方法更为有效的软件设计模式，构件软件被广泛应用并成为一种主流软件形态3（本段及后两段中的“构件”与论文中的“组件”概念一样，只是翻译的不同）。然而，构件的内部信息屏蔽、演变速度快以及构件间的异质、松耦合等特点给构件及构件软件的测试工作带来一系列的问题4,5：对于构件提供者，问题在于需要使用相当充分的覆盖准则进行测试以提高构件的可复用性；对用户使用构件的上下文环境并不完全了解；并且不能很好的获得构件的错误报告。对于构件使用者而言，问题在于源代码不可见性给测试设计和用例生成带来了极大的障碍6；系统中构件的异质性不利于测试标准的统一及自动化的实现；构件版本更新快以及不确定性迫使要对构件系统进行较为频繁的回归测试等。构件软件测试通常分为构件测试、子系统测试、系统测试三个阶段7，分别与传统软件测试过程的单元测试、集成测试和系统测试相对应。Harrold8认为应该从构件开发者和构件使用者两个不同的角度来看待构件软件的测试问题。一般来讲，构件测试主要由构件的开发者完成，而后两个阶段的测试则由使用者实施。总之，根据构件自身的特点，寻求高效的构件软件测试技术和开发实用的测试工具是当今软件业界一个亟待解决的问题。相对于构件测试的研究，针对缓冲区溢出攻击的研究比较成熟。缓冲区溢出攻击可追溯到1988年臭名昭著的Morris蠕虫， 在随后的1989年里，Spafford提交了一份关于运行在VAX机上的BSD版UNIX的fingerd的缓冲区溢出程序的技术细节的分析报告，这引起了一部分安全人士对这个研究领域的重视。但真正让众人认识缓冲区溢出攻击的论文是1996年11月Aleph One在Phrack杂志第49期发表的论文“Smashing the stack for fun and profit”9。该论文阐述了Linux系统中栈的结构和如何利用栈缓冲区溢出，并首次提出shellcode的概念。1999年，IIS4.0远程攻击代码的作者dark spyrit AKA Barnaby Jack10在Phrack Magzine（第55期）上提出了使用系统核心DLL中的“jmp esp”的指令来完成到shellcode跳转的想法，从此开创了Win32平台下缓冲区溢出的新思想，大量Windows平台下的缓冲区溢出漏洞也被利用。在缓冲区溢出漏洞挖掘和检测方面，国外已经有一些较为深入的研究工作，并且这些技术都能应用到在Win32平台下开发的软件中，而国内的研究还处于初级阶段。通过对目前国内外相关研究文献的搜集整理，按照各种技术的研究对象的不同，可将缓冲区溢出漏洞检测的研究工作进行如下分类11,12,13：1、基于源代码的静态检测技术：将源代码作为输入，通过建立漏洞库，扫描源代码，匹配漏洞模式来检测缓冲区溢出漏洞。目前关于此方面的研究较多，典型的工具有ITS414、BOON15、Splint16,17、ARCHER18等。2、基于源代码的动态检测技术：可通过扩展编译器功能和直接修改源代码来完成溢出漏洞的检测，如StackGuard19,20和STOBO21等工具。3、基于二进制代码的动态检测技术：通过静态或动态修改二进制代码和采用“黑盒测试”的方法实现栈溢出漏洞检测，如RAD22、libverify23和Fuzz24等工具。4、基于二进制代码的静态检测技术：该技术的研究目前比较少见，目前典型的研究是通过一些反汇编工具对目标代码进行处理，然后再依赖一些源代码静态检测技术进行处理25,26,27，如Terry Eruce Cillette28、bugscam29,30等工具。漏洞检测方法各有利弊，需要根据具体情况选择相应的方法来确保最大程度上挖掘出缓冲区溢出漏洞。在上述的研究工作中，基于二进制代码的静态检测技术对于针对COM组件的缓冲区溢出检测具有指导意义。论文中的检测技术就是归属于基于二进制代码的静态检测技术的。1.3 论文主要研究工作论文的主要工作为：在研究已有缓冲区溢出检测技术，分析现存成熟的缓冲区溢出检测工具，研究C/C+程序的逆向技术以及参加实验室的针对COM组件的安全漏洞自动化检测工具的开发的基础上，设计了一种针对COM组件二进制代码的栈缓冲区溢出漏洞检测算法SBOD-BC-CC(stack buffer overflow detection based on binary code of COM component)，并最终实现一个COM组件栈缓冲区溢出检测原型系统。具体工作包括：1、现有的栈缓冲区溢出检测技术的总结对现有的栈缓冲区溢出检测技术进行了深入的研究，将溢出检测技术分为四大类：基于源码的静态检测、基于源码的动态检测、基于二进制代码的静态检测和基于二进制代码的动态检测。详细分析了这四类技术并介绍了各自的代表自动化工具。在分析现有检测技术的基础上，提出论文研究的检测技术。2、C/C+程序的逆向技术研究熟悉反汇编工具IDA、OllyICE和Win32dsm，熟练掌握IDC脚本语言。研究在汇编代码中识别程序流程，识别函数（库函数和用户编写的函数），识别函数的参数，识别函数的变量等技术，在研究识别库函数的过程中提出了一个切实可行的算法。3、函数定位模块的实现为了减少扫描汇编代码得到的无用信息，提高检测效率。根据COM组件结构特点，设计了一种自动识别接口函数的算法，并实现了一个函数定位模块，可以将COM组件中用户函数名和该函数在汇编代码中的线性地址实现精确定位。4、COM组件危险函数库的建立栈缓冲区溢出通常发生在字符串操作函数中，对于一般的C/C+程序，使用的是C字符串，所以危险函数库主要是由常规字符串操作函数（如strcpy、strcat等）的子集构成。但COM组件中使用的是混合字符串。常规的字符串操作函数无法处理该类型字符串。因此必须建立适用COM组件的危险函数库。5、栈溢出检测算法的实现在详细分析bugscam的基础上，对其两大核心函数SHeapBuffSize和函数StckBuffSize做了改进。利用IDA的脚本语言IDC实现了一个完整的栈溢出检测算法SBOD-BC-CC。该算法可以根据危险函数的参数类型，识别不同的赋值操作指令，从而较准确的得到参数代表的缓冲区的分配长度和使用长度。依据缓冲区溢出的标准，判断栈溢出漏洞。同时通过识别函数调用的操作指令，并结合函数定位模块，可以提取用户函数的依赖关系，以XML格式输出的函数依赖关系为COM组件的后续分析提供良好的输入信息。1.4 论文结构第一章为绪论，主要介绍论文研究内容的一些背景情况，国内外研究现状和论文的主要内容。第二章首先介绍了COM组件，然后对缓冲区溢出的机理做了分析。重点介绍了栈缓冲区溢出的原因和分类，同时比较分析了现有的栈缓冲区溢出检测技术和工具。第三章重点介绍静态分析的理论基础，研究如何从二进制代码中识别高级语言的关键结构。介绍了在汇编代码中识别函数，识别函数参数，识别函数返回值以及识别函数变量的技术。同时讨论了COM组件危险函数库的建立。第四章详细介绍COM组件的栈缓冲区溢出漏洞检测系统的设计与实现。第五章介绍对实现的原型系统进行的测试与分析。第六章是对本文工作的总结和展望。2 COM组件及栈缓冲区溢出漏洞检测方法基础COM组件在受到广泛应用的同时，自身的安全问题也日益暴露。其中，缓冲区溢出安全问题占了很大的比例。为了提高组件软件的健壮性，针对COM组件缓冲区溢出漏洞检测方法的研究具有十分重要的意义。本章首先简单介绍了COM组件，然后详细介绍了缓冲区溢出原理和目前成熟的检测方法及工具。2.1 COM组件COM组件是符合COM规范编写的组件。COM是由Microsoft提出的组件标准，不仅提供了组件之间的接口标准，还引入了面向对象的思想。在COM标准中，对象是某个类的实例，称为COM对象。接口是一组方法的集合，其方法也称为接口成员函数。COM组件为COM对象提供活动空间，COM对象以COM接口方式提供服务。COM组件、COM对象和COM接口三者之间的关系如图2.1所示31。图2.1 COM组件、COM对象和COM接口关系COM组件有两种，一是进程内组件，是一个DLL（动态链接库）文件；二是进程外组件，是一个EXE（可执行程序）文件。当组件的客户程序调用组件的功能时，首先创建一个COM对象，然后通过该对象实现的COM接口调用所提供的服务。当所有的服务结束后，如果客户程序不再使用该COM对象，那么应该释放掉COM对象所占有的资源，包括对象本身。组件的内部实现对客户程序是完全隐藏的。2.1.1 COM对象COM提供的是面向对象的组件模型，COM组件提供给客户的是以对象形式封装的实体。客户程序与COM组件通过COM对象交互。COM规范采用了128位全局唯一标识符GUID来标识COM对象。与C+对象相比两点不同：1、COM对象的数据成员的封装以组件模块为最终边界，对于对象用户是完全透明的；而C+对象的封装特性相比之较差，可能对于用户是可见的。2、COM对象的可重用性通过COM对象的包容和聚合来实现；而C+对象的可重用性是通过继承机制实现的。2.1.2 COM接口1、接口的定义接口是一组逻辑上相关的函数集合。COM对象通过接口成员函数对外提供服务。接口的传统命名前缀为I。COM模型中，客户程序通过接口获得对象的服务。每个接口由一个128位的全局唯一标识符IID来标识，客户通过IID获得接口的指针，再通过接口指针调用相应的接口成员函数。COM规范使用IDL（接口描述语言）来定义COM接口。Microsoft Visual C+提供了MIDL工具，可以把IDL接口描述文件编译成C/C+兼容的接口描述头文件（.h），该文件可以被组件程序和客户程序所使用。2、接口的内存结构客户程序用一个指向接口的指针来调用接口方法，接口指针又指向另一个指针(pVtable)，pVtable指向接口函数表（vtable），接口函数表的每一项为4个字节的函数指针，每个函数指针与对象的函数实现连接起来（如图2.2所示）。接口指向的虚函数表是确定的，即接口的成员函数个数和先后顺序是不变的；对于每个成员函数来说，其参数和返回值也是确定的。不管什么语言，只要能支持这样的接口内存结构描述，就可以定义接口。图2.2 COM组件接口结构3、IUnknown接口COM定义的每一个接口都必须从IUnknown接口继承。IUnknown接口提供了接口查询和对象生存期管理的功能。如果客户要对对象进行操作，则必须保证对象存在于内存中；如果客户对对象的操作完成，则必须把对象从内存释放掉。IUnknown接口采用引用计数方法，可以有效的控制对象的生存期。IUnknown接口包含3个方法：QueryInterface、AddRef、Release。QueryInterface用于完成接口之间的跳转，查询COM对象的其它接口；AddRef和Release用于对引用计数进行操作：当调用AddRef时，对象的引用计数加1；当调用Release时，对象的引用计数减1。当对象的引用计数为0时，对象可以自己释放自己。2.2 缓冲区溢出原理除了人为因素外，缓冲区溢出主要源于现有系统中的进程内存分配和结构布局，非类型安全语言的使用以及危险函数的使用等问题。2.2.1 缓冲区溢出机理缓冲区溢出是向一个缓冲区填充超过它处理能力的数据所造成的结果9。危险函数是指可能导致缓冲区溢出的C标准库函数和系统API。广义的“缓冲区”是指应用程序中定义的变量在进程中对应的内存位置。在C程序中定义的全局变量或用关键字static定义的静态变量，已被初始化的分配在数据区，而未被初始化的则位于BSS区；用内存分配函数分配的变量位于堆区；函数中的局部变量被分配在堆栈区。这些内存区域的分配位置如图2.3所示。图2.3 Windows内存分布一方面，程序中为变量分配的缓冲区在进程对应的内存结构中具有固定的大小，另一方面由于C语言不进行边界检查，在给变量直接或间接赋值时，如果不加以注意，变量有可能被分配到一个超过其对应缓冲区大小的数据，导致缓冲区溢出。当程序试图访问已分配的缓冲区以外的内存时，将出现下列三种情况之一：一是内存不存在，系统报错；二是系统提供了内存保护的功能，报段错或保护错；三是允许访问，但将覆盖缓冲区一侧的内容，轻则留下安全隐患，成为日后被入侵者攻击的弱点，严重的会导致系统崩溃。被溢出的缓冲区若位于堆栈段，则称为堆栈溢出，若位于data、bss、heap段，则称作堆溢出。本文设计的漏洞检测系统主要针对的是栈溢出漏洞。1、堆栈定义堆栈是一块保存数据的连续内存。一个名为堆栈指针（ESP）的寄存器指向堆栈的顶部。堆栈的底部在一个固定的地址。堆栈有两个重要的操作PUSH和POP，分别实现向堆栈中添加元素和从中移去元素。2、堆栈帧堆栈由逻辑堆栈帧组成。当调用函数时逻辑堆栈帧被压入栈中,当函数返回时逻辑堆栈帧被从堆栈中弹出。堆栈帧包括函数的参数,函数的局部变量,以及恢复前一个堆栈帧所需要的数据,其中包括在函数调用时指令指针(EIP)的值。3、堆栈增长方式堆栈既可以向下增长（低端地址）也可以向上增长,这依赖于具体的实现。在很多计算机的实现方式中，包括Intel，Motorola等处理器，堆栈是向下增长的。堆栈指针（ESP）也是依赖于具体实现的。它可以指向堆栈的最后地址，或者指向堆栈之后的下一个空闲可用地址。本文中,堆栈是向下增长，ESP指向堆栈的最后地址。4、栈溢出的原理函数调用时的堆栈分配过程中，非静态局部变量缓冲区的分配和填充不是同时进行的，并且依据不同的标准：局部变量缓冲区的分配是依据局部变量的声明，而填充则是依据其实际被赋予的值。因此这个过程中就出现了安全漏洞。当对局部变量填充的值长度超出分配的值长度，而程序中又缺乏边界检查机制时，数据就会继续向栈底写入，相继覆盖其他变量的缓冲区、EBP和EIP等，如图2.4所示。EBP是定位函数形参和局部变量的标杆，EIP决定函数调用结束后的返回地址，二者一旦出错轻则使程序运行不正常，重则出错终止，甚至被他人取得程序的运行权进而控制本机。攻击者只要在程序运行时传送给它一个足够大的参数，就可以在返回地址EIP中填入一个攻击者希望程序转向的任意内存地址，从而控制了程序的运行权。这也就是基于堆栈的缓冲区溢出攻击的原理。2.2.2 栈缓冲区溢出分类1、根据溢出破坏的内容分类John Wilander和Mariam Kamkar32根据栈溢出所破坏的内容将栈溢出分为六种类型：（1）破坏函数返回地址；（2）破坏原栈帧基指针；（3）破坏作为变量的函数指针；（4）破坏作为函数参数的函数指针；（5）破坏作为变量的longjmp缓冲区；（6）破坏作为函数参数的longjmp缓冲区；在C语言中包含了一个简单的检验/恢复系统，称为setjmp/longjmp。头文件中声明了这些函数，并且定义了jmp_buf数据类型。setjmp(jmp_buf j)必须首先被调用，它表示“使用变量j记录现在的位置，函数返回0”。longjmp(jmp_buf j,int i)可以接着被调用，根据jmp_buf结构中保存的程序现场实现跳转。jmp_buf 结构存放了程序当前寄存器的值，以确保使用longjmp后可以跳回到该执行点上继续执行。VC6.0编译器对其在X86下的定义如图2.5所示。图2.4 函数调用时的栈帧图2.5 jmp_buf数据结构然而，如果能在longjmp函数执行以前覆盖掉jmp_buf，就能重写寄存器EIP的值，当longjmp函数恢复保存的堆栈栈帧后，程序就可能跳到指定的地方去执行。类似函数指针，longjmp缓冲区能够指向任何地方，所以攻击者所要做的就是找到一个可供溢出的缓冲区。2、根据溢出的方向分类根据栈溢出的方向可以分为“栈上溢”和“栈下溢”，比如固定大小的缓冲区的正负越界操作就会发生栈上溢和栈下溢。3、根据溢出改写数据的方式分类根据栈溢出时对数据的改写方式是否连续24，可以分为连续的栈溢出和不连续的栈溢出，目前的大多数检测工具都只能检测连续的栈溢出。2.3 栈缓冲区溢出检测技术目前，在缓冲区溢出检测技术研究方面，国外的研究比较深入，而国内的研究尚处于起步阶段33。总体上，栈缓冲区溢出的检测技术可分为两类：静态检测技术和动态检测技术。静态检测技术指的是不依赖于程序的运行检测出栈溢出漏洞的技术。静态检测一般发生在编译前和编译后，分为基于源代码的静态检测和基于二进制代码的静态检测。基于源代码的静态检测技术是目前研究相对较多的一个分支。基于二进制代码的静态检测技术的研究目前比较少见，其本质也是基于“源码”的检测技术。动态检测技术指的是检测过程必须依赖于程序的运行，一般需要在程序中插入或者修改一些代码来检测栈溢出漏洞。动态检测可分为基于源代码的动态检测和基于二进制代码的动态检测。基于源代码的动态检测可通过扩展编译器和直接修改源代码来完成溢出漏洞的检测。基于二进制代码的动态检测通过静态或动态修改二进制代码和采用“黑盒测试”的方法实现栈溢出漏洞检测。当前栈溢出检测技术的总结如图2.6所示。图2.6 现有栈溢出检测技术总结2.3.1 基于源代码的静态检测技术基于源代码的静态检测技术是目前研究相对较多的一个分支，通过基于源代码的词法分析、模型化、标记驱动、语法分析等静态分析技术完成栈溢出漏洞的检测34。1、词法分析该技术的代表检测工具是ITS4。ITS4是最早的以命令行方式工作在Linux和Unix环境中的一种静态扫描C/C+源代码中安全漏洞的简单工具。ITS4构造了一种具有安全威胁模型结构的数据库，然后使用词法分析技术对源码进行对应模式的搜索匹配。它可以发现一些最普遍的安全漏洞。2001年发布的基于Python语言开发的用来安全审查C/C+语言程序的工具FlawFinder35和同年发布的RATS35与ITS4的工作原理相同，都是先建立漏洞数据库，然后通过对源程序进行词法分析进行模式匹配，找到潜在的漏洞。这类检测技术的特点是实现简单、算法效率高，但是由于没有考虑到语法和语义层次的信息，容易出现漏报和错报问题。2、模型化可以将缓冲区溢出检测形式化为整数限制求解问题。代表检测工具是BOON。BOON(Buffer Overrun Detection)是加州伯克利大学的David Wagner博士在其博士论文中实现的原型系统，将检测缓冲区溢出问题转化为整数范围分析问题。BOON不检测格式化字符串漏洞的扫描，而且检测结果存在大量的误报和错报，但作者明确表示不再有更新的版本，所以近年来在这方面并无新的研究进展发布。3、标记驱动该技术的代表检测工具是Splint。LCLint是David Evans等人在Lint工具的基础上开发的一种使用规范来检查代码安全性的工具。2002年一月初LCLint改名为Splint(Secure Programming Lint)，专门检测程序的安全问题。Splint要求程序员在C源码中按照固定的注释格式/*.*/加入标记，这些标记被当作规格属性，根据标记在每个函数中增加事先条件和事后条件（事先条件是指函数参数必须满足指定的限制，事后条件保证函数结果满足一些限制要求），然后利用词法分析等技术验证标记的限制条件与程序是否一致。Splint不能很好的处理指针的运算。使用标记驱动技术的另一成熟检测工具是Nurit Dor36等开发了一种名为CSSV的缓冲区检测器的原型系统，其创新处在于引入契约的概念。4、语法分析Yichen Xie等开发了一种名为ARCHER的检测工具。ARCHER的核心处理过程大致如下：首先对源码进行语法分析，生成抽象语法树AST，然后利用工具构造相应的程序流程控制图，在其上进行路径敏感分析。在对Sendmail、Linux等一些开放源码的系统测试中，ARCHER取得了不错的效果。除了上述几种工具外，Vinod Canapathy37等人提出一种基于线性规划和静态分析理论的轻量级别检测算法，该算法首先使用工具软件生成一些指针相关的信息和抽象语法树，然后生成一些线性约束，并利用线性规划的思想来完成区间分析，检测可能出现的溢出漏洞。该算法主要围绕着商业工具软件Codesurfer来实现的。2.3.2 基于源代码的动态检测技术基于源代码的动态检测技术一般需要在程序运行之前在程序中插入或者修改一些指令来检测栈溢出。根据插入代码方式的不同，可分为扩展编译器和直接修改源码的检测技术。1、扩展编译器扩展编译器的技术是指对现有的编译器进行扩展，通过编译器收集栈的信息，增加缓冲区边界信息并插入边界检查代码，以实现对栈溢出的检测。根据栈溢出检测方式的不同，目前常用的两种方法是基于“canary”的边界检查和数组边界检查。（1）基于“canary”的边界检查基于“canary”值的边界检测主要是由Cowan提出来的一种检测策略。目前该策略的实现工具StackGuard受到了广泛应用。StackGuard是一个GCC编译器的补丁，援引StackGuard作者的话，StackGuard是一种“用轻微的性能损失来消除堆栈溢出问题的编译