简介
软件安全是高科技工业比较关心的内容。最令人害怕和难以理解的软件攻击就是缓冲区溢出。今天，一提到缓冲区溢出，人们都比较关注。在记录缓冲区溢出攻击时经常缺乏技术细节，一般人对这个问题除了有一个令他吃惊的印象外再无其它。为了解决这个问题，Visual C++ .NET引进了安全检查来辅助开发者确定缓冲区溢出。
什么是缓冲区溢出？
缓冲区是一块内存，通常以数组形式存在。如果不检查数组的大小，那就有可能写到分配的缓冲区以外的地方。如果这种情况发生在比缓冲区高的内存地址上，它就叫作缓冲区溢出。当写到比缓冲区低的地址时，会发生类似的情况。这种情况被叫作缓冲区下溢。下溢与溢出相比非常少，但是就像本文后面描述的那样，它们确实都会出现。利用缓冲区溢出可以将代码注入到一个进程当中，这样的缓冲区溢出就是可利用的缓冲区溢出。
一类有详细文档的函数，包括strcpy，gets，scanf，sprintf，strcat等等，自身容易受到缓冲区溢出的攻击，因此不鼓励使用它们。下面的例子说明了这种危险性：
int vulnerable1(char * pStr) {
int nCount = 0;
char pBuff[_MAX_PATH];
strcpy(pBuff, pStr);
for(; pBuff; pBuff++)
if (*pBuff == '\\') nCount++;
在这种情况下，在定义缓冲区大小时使用的是字节数而不是字符数，从而导致溢出。要更正这个问题，MultiByteToWideChar函数的最后一个参数应该改为sizeof(buf)/sizeof(buf[0])。vulnerable1和vulnerable2中的错误很常见，并且也很容易避免。然而，如果没有回过头去再看一看代码，潜在的安全威胁就可能存在于最终的应用程序中。这就是Visual C++ .NET引进安全检查的原因，它能阻止利用vulnerable1和vulnerable2中的缓冲区溢出将恶意代码注入到一个易受攻击的应用程序中。
运行时检查
缓冲区溢出是C或C++程序员经常犯的错误，它也是最危险的。Visual C++ .NET提供了一些工具帮助开发者在开发周期中可以很容易地发现这些错误并修复它们。Visual C++ 6.0中的编译器参数/GZ，在Visual C++ .NET中被称为/RTC1。它是/RTCsu的别名，其中s代表堆栈检查（stack check），这是本文讨论的重点，u代表未初始化的变量检查（uninitialized variable check）。所有在堆栈上分配的缓冲区其边界都被作了标记。因此，溢出和下溢都能被捕获。可能比较小的溢出不会改变程序的执行，因此不太引人注意，但是它可能毁坏缓冲区附近的数据。
运行时检查对那些不仅想写出安全的代码而且关心写出正确代码原则的开发者来说非常有用。但是，运行时检查只对程序的调试版本有用。这个特性并不是为最终的产品级代码而设计的。但是，在产品级代码中检查缓冲区溢出的价值显而易见。如果要这样做，那就需要设计一种对性能影响比运行时检查小的方案。最终，Visual C++ .NET编译器引进了/GS参数。
Cookie值
Cookie是一个与指针大小相同的随机值，也就是说，在x86平台上，cookie是四字节长。这个值保存在__security_cookie变量中，和其它CRT全局数据放在一起。它的值通过调用__security_init_cookie函数被初始化成一个随机值，这个函数定义在CRT源文件中的seccinit.c文件中。它的随机性来自于处理器的计数器。每个映像（也就是说，每个带/GS参数编译的DLL或EXE，）在加载时有一个独立的cookie值。
创建应用程序时带/GS参数可能引起两个问题。首先，不使用CRT支持的应用程序会缺少随机的cookie值，因为对__security_init_cookie的调用发生在CRT初始化期间。如果cookie值不是在加载时随机设置的，应用程序仍然容易受到缓冲区溢出的攻击。为了解决这个问题，应用程序需要在启动时明确调用__security_init_cookie函数。第二，通过调用_CRT_INIT函数来初始化的一些早期应用程序可能发生不可预料的安全检查失败，如下例所示：
DllEntryPoint(...) {
char buf[_MAX_PATH]; // A buffer that triggers security checks
...
_CRT_INIT();
...
}
问题在于当已经设置好安全检查的函数处于活动状态时，对_CRT_INIT的调用改变了cookie的值。这样，因为cookie值将与函数退出时的cookie值不同，安全检查认定有缓冲区溢出。解决办法是，避免在活动函数中调用_CRT_INIT函数前定义缓冲区。目前，有一种可行的方法是使用_alloca函数在堆栈上分配缓冲区，因为编译器并不为_alloca分配的缓冲区生成安全检查代码。但是，并不能保证这种方法在将来版本的Visual C++ 上仍然有效。
性能影响
使用安全检查的应用程序必须付出的代价是性能降低。Visual C++ 开发团队尽全力把性能损失降到最低。大多数情况下，性能损失不超过2%。事实上，对大部分应用程序，包括高性能的服务器应用程序的测试显示，观察不到任何性能影响。
只有那些可能受到攻击的函数才被设置进行安全检查，这是保持性能不受大的影响的最重要的因素。目前，对可能受到攻击的函数的定义是，函数在堆栈上分配了符合某些条件的字符串缓冲区。这些条件就是字符串缓冲区超过了四个字节，并且其中的每个元素是一个或两个字节。比较小的缓冲区不可能成为攻击目标。毕竟，限制了需要进行安全检查的函数数目也就是限制了需要额外增加的代码的长度。大多数可执行文件带/GS选项创建时甚至观察不到大小增加。
示例
因此来说，/GS选项并没有修复缓冲区溢出，但是它能在某些情况下阻止缓冲区溢出被利用。当带/GS选项编译vulnerable1和vulnerable2时，它们的缓冲区溢出都是安全的。任何函数，只要它发生缓冲区溢出后立即返回，那么它的缓冲区溢出就是安全的。由于函数刚开始执行时就可能发生缓冲区溢出，因此可能存在下列情形：要么安全检查还没有得到机会检测缓冲区溢出，要么安全检查自身也被缓冲区溢出攻击，正像下面这个例子那样：
例1
class Vulnerable3 {
public:
int value;
Vulnerable3() { value = 0; }
virtual ~Vulnerable3() { value = -1; }
};
