有关security cookie在栈保护上的研究

有关security cookie在栈保护上的研究 06.10 by flyingkisser 这里主要讨论栈，不是堆。 首先，security cookie并不是windows系统自带的保护机制，并不是说一个确实存在溢出漏洞的 程序，放到带security cookie保护的环境中，就不能正常溢出了。 那么，到底是什么是security cookie呢？ 我觉得从广义上讲，它应该是一种保护栈的机制，提供这种保护的，是程序本身，编译进程序本身的 代码提供的，而不是系统中某个运行在黑暗角落中的线程。 所以，既然是程序自身就带上的，为了不给程序员带来额外的负担，这份工作就交给编译器来完成了。 vc6.0的cl.exe是不带这个功能的，只有vc.net以后面版本的cl.exe才带这个功能，就所谓的/GS选项。 即用vc.net的cl编译器时，/GS选项默认就打开了。 现在，我们知道了这个机制的提供方，那么，这个机制到底是怎么一回事呢？ 熟悉函数调用及返回前后的汇编指令的人肯定很清楚，在win32平台，对于stdcall类型的函数调用， 当call指令运行完毕，当前的堆栈结构基本上是这样的： 局变2 ebp-8 低地址 局变1 ebp- 4 ebp ebp 返回地址 ebp+4 参数1 ebp+8 参数2 ebp+c 参数3 ebp+10 参数4 ebp+14 高地址 第一列是堆栈中存放的dword的内容，第二列是用ebp作为栈地址的索引时，它对应的应该用ebp表示的值， 说得形象一点，ebp中存放着栈的一个地址(栈其实也是一片内存，ebp只是指向其中一个对当前函数内部比较 重要的地址，其实是相当重要)，栈的其它位置都是通过这个ebp来寻址的，即我们给函数的第一个形参的 地址，就是ebp+8,第二个就是ebp+c,我们定义的局部变量的地址，第一个局部变量是ebp-4,第二局部变量的 地址就是ebp-8，依此类推。但这也不是一定的，上面说的是理想情况，如果我们在函数里定了一个数组， 如 char buf[8];并且是定义的第一个局部变量，那么它的地址肯定就不是ebp-4,还是ebp-8。所以，数组 比较特殊，结构体也比较特殊，其根本原因是栈是从高地址向低地址生长的，而我们的数组，结构体， 却是从低向高地址生长的，两者矛盾的结果就是寻址上的微妙变化。 当然，这里为了方便说明问题，都默认定义的变量，传入的参数，都是四字节对齐的，并且一个变量一个 双字。你可以把数组理解一个4字节的char,也就是一个双字了。 话说回来，当call运行完毕，当前的堆栈结构已经给出，如果在函数里调用strcpy()往局部变量1 里考入 东西，对长度没有进行检测，那么ebp-4,ebp,ebp+4,还有后面的地址，其所在的内容都会被覆盖掉。这里 溢出就发生了，我们控制住了ret的返回地址，然后... 嗯，为了防止这一切，新的cl编译器的/GS选项加上入所谓的"security cookie"，如何加入的？在哪加入的 呢？ 先看看加入"security cookie"后的call指令运行完以后，堆栈的变化。 局变2 ebp-c 低地址 局变1 ebp-8 XXXXX ebp-4 ebp ebp 返回地址 ebp+4 参数1 ebp+8 参数2 ebp+c 参数3 ebp+10 参数4 ebp+14 高地址 变化很明显，在ebp上面，第一个局部变量的下面，填入的一个新的值，这个值就是所谓的"security cookie" .按照前面说的溢出过程，ebp- 4的内容被覆盖掉，即security cookie的值被修改，在函数返回，即执行ret 指令前，会call另一个函数，这个函数就是用来对比 ebp-4的值和当时push到栈中的值是不是一样，不一样的 话，就说明溢出了，然后进程被终止。 那么，你大概会产生以下几个问题： 1. 这个security cookie是如何计算出来的？ security cookie是一个双字，也可以说是一个int,其本身是保存在全局变量里的，其创建是编译器在编译 阶段就创建的，然后写入到.data段里，即在PE里就保存了这个值。 但这个值又是变化的，windows装载器完成必要的前期准备工作后(如创建进程，为栈分配内存，等待) 把 EIP设置为PE里的代码入口处，第一个执行的指令就是一个call调用，这个call调用就是用来初始化这个 cookie值的，当然，这段代码也是公开的，但没有关系，这个算法保证这个cookie值是随机的，hacker也 是不能在一个shellcode中可以猜出来的。 具体算法我不打算在此说明，感兴趣的读者可以自己编译一下再反汇编一下看看。 2.是什么时候填入到栈里面的？ 我们知道了这个 security cookie的计算和初始化过程，那么，它必须在函数调用时写入到ebp-4里面才有用。 所以，过去的不带这种保护的代码，在函数入口处一般是这样的： push ebp mov ebp,esp sub ebp,n ;这条指令可能不同，不过多数情况下都是这样来为局部变量分配空间的 然后，后面就开始执行我们的代码了， 加入这种保护后，会在sub ebp,n后面，加入一条像这样的指令： mov dword ptr [ebp-4],XXX XXX就是security cookie的值，这个值保存在全局变量里，通过RVA＋PE头地址，实际上也可以说成是 绝对地址来引用了。 到这里security cookie的值就写入栈了，然后在函数返回前检测一下就行了。 到了这里，你大概又会产生一个新的问题， 必须为每一个函数调用都写入security cookie进行保护吗？ 答案是否定的，要不然我们的程序的执行效率会受到一定的影响，并且可能还不小。 那么，就应该存在一定的规则，什么时候进行这种保护，什么时候不需要。 其依据当然也很简单，有溢出可能的，就加入这种保护，没有溢出可能的，就不加。 那怎么样才算是有溢出可能呢？ 这个是编译器进行判断的，像函数里定义了char数组，后面又用字符串操作函数进行了一定的操作，就说明 可能存在溢出。编译器在编译这个函数里的时候就加上security cookie的保护。 当然，这里还有一些其它的很具体的规则，在msdn里有更详细的描述。 还有其它一些问题没有在这里说明，可以把这些问题留给大家 1.有对付security cookie的检测的方法吗？(答案是有的，但好像都不是很优美) 2.有关security异常的异常处理函数 3./safeSEH对 SEH处理的变化