___security_cookie

标签: ,

用IDA Pro反汇编某个程序时发现很多函数都有___security_cookie这个东西,Google了一下,原来是GS编译选项搞的鬼。

有关security cookie在栈保护上的研究
其实不是什么新东西了,也不是多高深的技术,在此只是写写我的一点研究心得而已。
这里主要讨论栈,不是堆。
首先,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处理的变化

原文链接:http://static.byr.cn/#elite/path?v=/groups/sci.faq/Security/hacker/BufferOverflow

赞赏

微信赞赏支付宝赞赏

随机文章:

  1. Ubuntu从NTP服务器同步时间
  2. Unable to find the socket transport "ssl" – did you forget to enable it when you configured PHP?
  3. PHP & JavaScript: UTF-16 to UTF-8
  4. 用VBS监视进程创建和删除
  5. BAT批处理编辑器BatEdit

留下回复