【原创】【原创】【原创】缓冲区溢出一例 __security_cookie

虽然来看雪很长时间了，但是这次是本菜鸟第一次在看雪发文章，还望各位高手前辈多多指教:):。本文记录一次崩溃的分析过程，旨在知识分享，别无它用。进入正题，前段时间一直在学习用windbg，看《软件调试》这本书，知道在xp下也有自带的一个调试器 – ntsd.exe。于是乎用ntsd绑住了notepad，然后!peb，结果ntsd就崩溃了，试了几次都是如此。我就纳闷了，难道我的ntsd用不了，不对啊，其它命令都没问题。想想这时该是windbg出场了！在ntsd绑住了notepad后，用windbg绑住ntsd，在ntsd上输入命令!peb，回车，windbg停了下来，kb如下：

从调用堆栈中来看，ntsd此时是在找符号文件，而且看来是干了坏事弹个报告错误的框就要走人了。看下DBGHELP!diaLocatePdb+0x758前面是在干什么

0结果又发现了__security_check_cookie，之前也遇到由这个函数报告出来的异常，那时的做法是通过屏蔽代码，最后才辛辛苦苦找出了导致异常崩溃的源头。这次又遇到了，一次代码屏蔽都那么辛苦，以后还遇到的话，这日子咋过了。恰巧，前几天也在看雪看到了一篇说到这个__security_check_cookie的问题，原理主要是在函数的开始调用过程时将__security_cookie的值保存到局部变量中，然后在函数退出的时候检查下，比较局部变量中的值相对于__security_cookie是否改变了，是的话，就证明函数在调用过程中不小心改掉了这个局部变量的值，目前我遇到的都是由于缓冲区溢出导致。先来看下这个函数：
由cmp ecx,dword ptr [DBGHELP!__security_cookie这句可看出，是用ecx的值来做比较，如果发现不同了，就跳到DBGHELP!__report_gsfailure处去处理了，最后就是弹出报告错误的框，确定后就退出进程了。从上可以看出，ecx的值是从外部调用传进来的，即ub DBGHELP!diaLocatePdb+0x758 L5时显示的mov     ecx,dword ptr [ebp-4]这句，看来__security_cookie就保存在ebp-4的地方。反汇编DBGHELP!diaLocatePdb如下：

从上面的反汇编代码证实了之前的猜测，接下来咱们就对dword ptr [ebp-4]这个局部变量的地址设写入断点，看看谁修改了它。
既然在找符号文件，就看看相关的函数在找哪个pdb文件了，我开始定位在DBGHELP!diaLocatePdb，看了下参数，发现DBGHELP!diaLocatePdb的第二个参数是符号文件名称，da 003f096c如下：

看来是在找这个pdb的时候ntsd崩溃了。接下来在DBGHELP!diaLocatePdb处下断点，bu DBGHELP!diaLocatePdb "da poi(esp+8);" ，其中poi(esp+8)为第二个参数的值。在重来一次，这时windbg断下了很多次，不过按多几下F5就过去了，直到ntsd在找MicrosoftWindowsCommon-Controls-6.0.2600.6028-comctl32.pdb文件时才停下来。

这时，单步执行汇编语句，直到mov     dword ptr [ebp-4],eax这一句汇编代码，windbg显示如下：

此时__security_cookie的值为0000f3c7， 看到ebp-4的值为00078718，先F10单步执行一下，然后对00078718该地址下写入断点，ba w4 00078718，F5运行，此时windbg停在DBGHELP!EnsureTrailingBackslash函数里的68d78e61 5e              pop     esi
一句，如下所示：

pop     esi这句是cpu接下来要执行的指令，所以导致异常发生的指令就是上一句了，即mov     byte ptr [eax+1],0。此时eax的值为00078717，再加1就是00078718了，这不就是之前保存__security_cookie的局部变量的地址吗！mov     byte ptr [eax+1],0，显然是它修改了之前那个局部变量的值。可是为什么会修改到这个地方呢？接下来继续往下看。
从DBGHELP!EnsureTrailingBackslash的反汇编代码中可以看出该函数主要是给指定的字符串末尾加上反斜杠。此时这个字符串是什么呢？从上面可以看出该字符串的地址是从外部传进来的，而且暂时放在了esi寄存器里面，目前还没有变过。此时da esi如下：

这个字符串的长度可以计算下
0:000> ? 00078714 - 00078614
Evaluate expression: 256 = 00000100
256再加上最后一行的四个字符总共是260个字符（不包括空结束符）。那这个从外面传进来的缓冲区有多大呢？此时函数调用堆栈如下：

看下调用DBGHELP!EnsureTrailingBackslash前的代码，

从上面可以看到传进来的缓冲区首地址是ebp-108，从ebp-108到ebp-4，这中间的缓冲区大小我们可以计算下：

0:000> ? 108
Evaluate expression: 264 = 00000108
除去保存__security_cookie的那个局部变量的四个字节外，就剩下只能够保存260字符大小的字符串了，前面的那个很长的字符串刚好是260，但是还要加上个结束符，结果就修改了保存__security_cookie的那个局部变量的值，最终造成ntsd崩溃了。此时那个局部变量的值为：

0:000> dd 00078718 L1
00078718  0000f300
之前__security_cookie的值为0000f3c7。至此，终于发现了那个神秘崩溃背后的真相，但是谁来拯救我的ntsd呢？:eek::eek::eek::eek::eek:
  从这次的分析中，可以看到__security_cookie可以很方便的查出问题的所在，以后就不用在遇到这种问题时，辛辛苦苦的屏蔽代码了！也许很多大牛都知道了如何处理__security_cookie的问题了，但这是本菜鸟第一次独立的分析，所以还是贴出来分享下这辛苦中的乐趣吧:eek:。
谢谢看雪论坛中牛人们的无私分享，让我这个菜鸟在看雪的日子里真地学到了很多，最后还要支持下看雪老大，希望看雪越来越好:):。