CVE-2010-0188漏洞点定位

每次看到一个个Oday放出，很多人往往感觉心有余而力不足。看到别人的报告，大多都是讲漏洞的细节，错误函数，畸形字节，但是都没有详细的讲调试的思路，如何定位poc触发的情况。当然，有时候也会有很多方面的原因，比如环境问题，poc的问题等等。最近看了一篇报告，原文地址在：

http://bbs.pediy.com/showthread.php?t=109316

就顺势写了一份如何捕获漏洞溢出点的帖子。有不对的地方还请指出。

环境：

Windows xp sp3 虚拟机

工具：

Windbg IDA OD

 

POC：

Exp->MessageBox (This is from to Metasploit)

 

Xp3中MessageBox的两个位置

MessageBoxA 77D507EA

MessageBoxB 77D66534

 

shellcode调用了MessageBoxA

直接在这两处都下断即可，这样我们就可以在shellcode没有结束的时候观察到函数栈帧的情况。

 

kd> k

ChildEBP RetAddr

0012da10 0336072c USER32!MessageBoxA

WARNING: Frame IP not in any known module. Following frames may be wrong.//这里说明堆栈被破坏导致windbg出现这种问题

0012da80 20b8f8b8 0x336072c

0012daa4 209fc5e8 AcroForm!DllUnregisterServer+0x379e0b

0012dad8 209db002 AcroForm!DllUnregisterServer+0x1e6b3b

00000000 00000000 AcroForm!DllUnregisterServer+0x1c5555

 

定位到的堆shellcode：

Source code   

kd> ub 0x336072c L30033606d0 7288            jb      0336065a033606d2 5c              pop     esp033606d3 240a            and     al,0Ah033606d5 89e6            mov     esi,esp033606d7 56              push    esi033606d8 ff5504          call    dword ptr [ebp+4]033606db 89c2            mov     edx,eax033606dd 50              push    eax033606de bba8a24dbc      mov     ebx,0BC4DA2A8h033606e3 871c24          xchg    ebx,dword ptr [esp]033606e6 52              push    edx033606e7 e861ffffff      call    0336064d033606ec 686f785820      push    2058786Fh033606f1 6861676542      push    42656761h033606f6 684d657373      push    7373654Dh033606fb 31db            xor     ebx,ebx033606fd 885c240a        mov     byte ptr [esp+0Ah],bl03360701 89e3            mov     ebx,esp03360703 6858202020      push    20202058h03360708 684d534621      push    2146534Dh0336070d 68726f6d20      push    206D6F72h03360712 686f2c2066      push    66202C6Fh03360717 6848656c6c      push    6C6C6548h0336071c 31c9            xor     ecx,ecx0336071e 884c2410        mov     byte ptr [esp+10h],cl03360722 89e1            mov     ecx,esp03360724 31d2            xor     edx,edx03360726 52              push    edx03360727 53              push    ebx03360728 51              push    ecx03360729 52              push    edx0336072a ffd0            call    eax  //这里EAX == MessageBoxW的位置

 

 

开启windbg查了一下  0x0336072a好像并不是堆的地址

Source code   

kd> !heap -hIndex   Address  Name      Debugging options enabled  1:   00150000     Segment at 00150000 to 00250000 (00023000 bytes committed)  2:   00250000     Segment at 00250000 to 00260000 (00006000 bytes committed)  3:   00260000     Segment at 00260000 to 00270000 (00003000 bytes committed)  4:   00390000     Segment at 00390000 to 003a0000 (0000d000 bytes committed)    Segment at 02140000 to 02240000 (0007b000 bytes committed)  5:   003c0000     Segment at 003c0000 to 003d0000 (00007000 bytes committed)  6:   003f0000     Segment at 003f0000 to 00400000 (00010000 bytes committed)    Segment at 01e10000 to 01f10000 (00100000 bytes committed)    Segment at 01f30000 to 02130000 (00200000 bytes committed)    Segment at 02c50000 to 03050000 (00400000 bytes committed)    Segment at 03660000 to 03e60000 (00580000 bytes committed)  7:   030f0000     Segment at 030f0000 to 03100000 (00004000 bytes committed)  8:   031b0000     Segment at 031b0000 to 031c0000 (00004000 bytes committed)

 

那么是模块地址咯？

加载shellcode我通过od找到离shellcode最近的栈帧

0012E3C0   7C801D7B  {€|  kernel32.LoadLibraryA

0012E3C4   7C81CAFA  亅    kernel32.ExitProcess

0012E3C8   03DA1AB0  ??

0012E3CC   FFFF0023  #.

0012E3D0   042785B8  竻‘

0012E3D4  /0012E464  d?.

0012E3D8  |20B8F8B8  给?    返回到 AcroForm.20B8F8B8 来自 AcroForm.20B8E767

 

然后跑到最近的栈帧这里看了一下。

20B8F8AD    57              PUSH EDI

20B8F8AE    FF75 08         PUSH DWORD PTR SS:[EBP+8]

20B8F8B1    8BCE            MOV ECX,ESI

20B8F8B3    E8 AFEEFFFF     CALL AcroForm.20B8E767

20B8F8B8    57              PUSH EDI

 

想了一下关于堆栈的结构，在思考一个问题。

缓冲区溢出往往只是破坏某一个栈帧的返回地址，而不会对整个栈帧破坏。

所以我猜测上面段代码极可能是漏洞出现的附近。

在虚拟机里面用ollydbg调试

 

Memory map, 条目 191

地址=20800000

大小=00001000 (4096.)

属主=AcroForm 20800000 (自身)

区段=

包含=PE 文件头

类型=Imag 01001002

访问=R

初始访问=RWE

 

可以发现地址是被映射进去的。这会导致我们无法对关键函数下断点。因为没有映射时，地址是不存在的，模块是Adobe AcroForm.api模块。

 

想想Adobe也必须要加载AcroForm吧

所以我对CreateFileW下了一个断点

 

7C814DF0    E8 FBB9FFFF     CALL kernel32.CreateFileW

7C814DF5    8BF8            MOV EDI,EAX

7C814DF7    83FF FF         CMP EDI,-1

7C814DFA    0F84 0BBF0200   JE kernel32.7C840D0B

7C814E00    56              PUSH ESI

7C814E01    56              PUSH ESI

7C814E02    56              PUSH ESI

7C814E03    6A 02           PUSH 2

7C814E05    56              PUSH ESI

7C814E06    57              PUSH EDI

7C814E07    E8 1446FFFF     CALL kernel32.CreateFileMappingW

就可以很轻松定位到这里，我要做的就是在它完成映射之后，在内存中下一个断点。

现在就可以很轻松的在CALL AcroForm.20B8E767下上断点了。 

继续分析…

现在可以在出问题的内存页下断点了。但是漏洞代码在哪里呢？

既然断下来了，我们回过头注意一下别人的分析:

看到那条Error fetching data的数据了吗？IDA有字符串搜索的。

                                                          

下面看看别人的分析报告和我实际的地址偏移：

Offset = 0x20CB55F3（报告中给出的图片) - 0x20C9B6F2(我本机的偏移) = 0x19F01

可以看到我的地址位置比报告提供的地址要低。

这样我就应该能在我的主机上找到所有关键函数的地址了.

下面就需要动态调试了，这次我们依旧使用od。

我同样在内存映射过后运行到了这里：

 

这里是覆盖后的。

这下终于定位到溢出的关键函数了。

 

下面就不对2010-0188的问题进行探索了，因为接下来的问题就是分析原本的文件结构，以及核心的汇编代码，这些网上太多例子。笔者时间也有限，也就简单提到这里了。这里只是起到画龙点睛的作用，文章作用并不是漏洞原理分析，而是说明一下如何根据一篇文章找到漏洞的关键点。