Visual C++.NET 2003（7.1）通过移动易受攻击的数据结构--（如异常处理方法的地址）--到堆栈中位于缓冲区之下的某个位置，增强了缓冲区溢出的保护力度。在编译器的7.0版本中，可通过破坏缓冲区与cookie之间的敏感数据，绕过安全cookie所提供的保护；然而，在新版本的编译器中，已把这些数据移到位于缓冲区下的一个区域，现在，想要通过修改这些数据而达到溢出，似乎是不太可能了。

　　图1演示了在C++编译器6、7.0、7.1中，堆栈概念上的布局，并演示了堆栈由高地址向低地址空间方向增长，这也是当程序执行时，堆栈增长的方向。堆栈向下增长，正是导致缓冲区溢出的主要原因，因为溢出会覆写在比缓冲区更高的内存地址空间上，而此正是易受攻击数据结构的栖身之地。

图1：堆栈逻辑布局

　　除了把异常处理方法等信息移到堆栈中数据缓冲区之下，Visual C++.NET 2003的链接器也把结构化异常处理方法的地址放到可执行文件的头部中。当异常发生时，操作系统可以检查堆栈中的异常信息地址，是否符合记录在文件头信息中的异常处理方法，如果情况不符，异常处理方法将不会执行。比如说，Windows Server 2003就可检查结构化异常信息，而此项技术也在Service Pack 2中移植到了Windows XP上。

　　而Visual C++ 2005（8.0）在此基础上又更进了一步，通常当有函数调用发生时，如果其中的一个本地缓冲区超出限度了，攻击者可能改写堆栈中在此之上的任何东西，包括异常处理、安全cookie、帧指针、返回地址和函数参数。而这些值的大多数被不同的机制所保护（如安全异常处理），但对一个有函数指针作参数的函数来说，仍有机会被溢出。如果一个函数接受一个函数指针（或结构、类中包含有函数指针）作为参数，攻击者就有可能改写指针中的值，使代码执行任何他想要的函数。鉴于此，Visual C++ 2005编译器将分析所有可能存在此漏洞的函数参数，并复制一份函数参数--并不使用原有的函数参数，把它放在堆栈中本地变量之下。如果原有函数参数被溢出改写了，只要副本中的值仍保持不变，整个函数就不会被攻破。

　应用缓冲区保护

　　只需简单地打开/GS编译器开关，就可启用缓冲区保护。在Visual Studio中，此开关可在"C/C++"选项页的"代码生成"选项中找到（如图2所示）。默认情况下，在Debug配置下为关，而在Release配置下为开。

图2：设置/GS开关 　　如果用最新版本的编译器进行编译，并生成结构化异常信息，那么在默认情况下，安全结构化异常处理将是打开的，另外，也可以使用/SAFESEH:NO命令行选项来关闭安全结构化异常处理，在Visual Studio的工程设置中，是没办法关闭安全结构化异常处理的，但仍可在链接器中使用此命令行选项来完成。 　　/GS及更远的安全前景 　　仅仅是打开一个编译器开关，不会使一个程序彻底变得安全，但在安全漏洞以各种形式出现的今天，它将有助于使程序更加安全。基于堆栈的缓冲区溢出是安全漏洞中的一大类，但随着黑客攻击技术的不断更新，相信它的谢幕，还有一段很长的路要走。 　　在Microsoft正式的术语中，/GS和SAGESEH均为软件强制的数据执行保护（DEP），软件强制的DEP也能以硬件的方式实现，如在实现了此功能的CPU中，如果数据出现在被标记为"不可执行"的内存页中，将不会执行它。Windows XP SP2及Windows Server 2003现在已支持这些技术，目前市面上的大多数的32位CPU及全部的64位CPU，都支持No Execute（NX）这类安全增强技术。 　　任何一个好的安全系统，均有多层防范措施应对安全威胁。本文所涉及的编译器开关，它能防范或减少普通编码错误所带来的安全隐患，而且它具有易于使用和低成本的特点，在这场没有硝烟的战争中，不失为一个好的解决方案，绝对值得你的程序采用。

上一页  [1] [2] 

（责任编辑：hahack）