UAF学习之Adobe reader CVE-2013-3346

　　学习了UAF，分析了几个漏洞，同时，也熟悉了windbg的用法，收获挺大。

　　基本的UAF分析流程如下：

　　　　i:找有漏洞的函数

　　　　ii:找到被释放对象的类型，以及被释放对象在内存中的位置

　　　　iii:理解对象的释放方式

　　　　iv:重写被释放对象的地址空间

　　　　v:理解漏洞的根本成因　

　　i：寻找有漏洞的函数

　　　　打开poc.pdf,出现了异常

(2f0.d64): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0c0c08a8 ebx=00000001 ecx=069d91c0 edx=292885fd esi=069d91c0 edi=00000000
eip=4a82f129 esp=002be1a0 ebp=002be1c4 iopl=0         nv up ei pl nz ac po cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210213
4a82f129 ??              ???

查看堆栈，来分析函数调用流程，如下：

0:000> kb
ChildEBP RetAddr  Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
002be19c 6257e85d 58e57dd9 00000001 069d91c0 0x4a82f129<2>
002be1c4 6257e0d2 00000000 069d91c0 00000000 AcroRd32_623e0000!DllCanUnloadNow+0x150536<1>
002be1e8 6257f3e3 002be23c 6257d996 6257f409 AcroRd32_623e0000!DllCanUnloadNow+0x14fdab
002be1f0 6257d996 6257f409 0681ad20 58e57e21 AcroRd32_623e0000!DllCanUnloadNow+0x1510bc
002be23c 6257c68c 00000000 58e57e71 0681ad20 AcroRd32_623e0000!DllCanUnloadNow+0x14f66f
002be26c 6257c50e 067dc0f0 0690caf0 58e57ee1 AcroRd32_623e0000!DllCanUnloadNow+0x14e365
002be2fc 6257c206 0681ad20 069763f8 002be318 AcroRd32_623e0000!DllCanUnloadNow+0x14e1e7

　　可知，函数是从6257e85d之前调用的：

0:000> ub 6257e85d
AcroRd32_623e0000!DllCanUnloadNow+0x150518:
6257e83f 897dfc          mov     dword ptr [ebp-4],edi
6257e842 ff96d0020000    call    dword ptr [esi+2D0h]
6257e848 0fb7d8          movzx   ebx,ax
6257e84b 8b06            mov     eax,dword ptr [esi]
6257e84d 59              pop     ecx
6257e84e 8bce            mov     ecx,esi
6257e850 66899ecc020000  mov     word ptr [esi+2CCh],bx
6257e857 ff9064030000    call    dword ptr [eax+364h]

　　可知，6257e857为crashfun

　　ii:找到被释放对象的类型

　　　　分析上面汇编，易知esi的地址的值为虚表指针：则可以通过esi和windbg来分析被释放类型，如下

0:000> !heap -p -a esi
    address 069d91c0 found in
    _HEAP @ 2ea0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        069d91b8 0071 0000  [00]   069d91c0    00370 - (busy)

　　大小为370，同时，esi的地址也为对象地址069d91c0

，可以得到。

　　iii:查看被释放对象在内存中的地址

　　观察异常前的堆栈

WARNING: Frame IP not in any known module. Following frames may be wrong.
002be19c 6257e85d 58e57dd9 00000001 069d91c0 0x4a82f129<2>
002be1c4 6257e0d2 00000000 069d91c0 00000000 AcroRd32_623e0000!DllCanUnloadNow+0x150536<1>
002be1e8 6257f3e3 002be23c 6257d996 6257f409 AcroRd32_623e0000!DllCanUnloadNow+0x14fdab

　　采用虚拟机回滚的方法来简便堆的调试

　　根据猜测，查看<1>的函数的调用处具体代码，并对该函数下断点。如下

eax=65f607a4 ebx= ecx=059f7d48 edx= esi=059f7d48 edi=
eip=6553e0cc esp=0022ddcc ebp=0022dde8 iopl=         nv up ei pl nz na po nc
cs=001b  ss=  ds=  es=  fs=003b  gs=             efl=
AcroRd32_653a0000!DllCanUnloadNow+0x14fda5:
6553e0cc ff909c020000    call    dword ptr [eax+29Ch] ds::65f60a40=6553e7f8

　　查看esp+8，即为对象地址。如下：

:> dd esp
0022ddcc   05a5bbc8
0022dddc     0022ddf0
:> !heap -p -a 05a5bbc8
    address 05a5bbc8 found in
    _HEAP @ 10a0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        05a5bbc0    []   05a5bbc8     - (busy)
          ? AcroRd32_653a0000!CTJPEGDecoderCreateUsingData+2b4134

:> dd 05a5bbc8
05a5bbc8  65f607a4  65f6077c
05a5bbd8   65f6073c  65f60728
05a5bbe8  05bc8bc0  02641ff8 

其中，05a5bbc8位置的值即为虚表指针。

　　iv:理解对象的释放方式。

　　直接通过buntdll!RtlFreeHeap ".if(poi(esp+0xc) == 05a5bbc8) {kb} .else{gc}"来查看堆栈的情况，并与crash时的堆栈进行对比，如下

0022d1c4 6553f5ae 00000001 00000000 05dd6c50 AcroRd32_653a0000!DllCanUnloadNow+0xa5956
0022d218 6553f41b 0022d24c 6553e848 05dd6c50 AcroRd32_653a0000!DllCanUnloadNow+0x151287
0022d220 6553e848 05dd6c50 2b83a232 00000001 AcroRd32_653a0000!DllCanUnloadNow+0x1510f4
0022d24c 6553e0d2 00000000 05a5c2d8 00000000 AcroRd32_653a0000!DllCanUnloadNow+0x150521
0022d270 6553f3e3 0022d2c4 6553d996 6553f409 AcroRd32_653a0000!DllCanUnloadNow+0x14fdab
0022d278 6553d996 6553f409 05dd6c50 2b83a2ba AcroRd32_653a0000!DllCanUnloadNow+0x1510bc

crash时：

0022dd9c 6553e85d 2b83adba  05a5bbc8 0x4a82f129
0022ddc4 6553e0d2  05a5bbc8  AcroRd32_653a0000!DllCanUnloadNow+0x150536
0022dde8 6553f3e3 0022de3c 6553d996 6553f409 AcroRd32_653a0000!DllCanUnloadNow+0x14fdab
0022ddf0 6553d996 6553f409  2b83ae42 AcroRd32_653a0000!DllCanUnloadNow+0x1510bc

可以得出，函数在堆栈情况如下的函数中进行了释放

0022d24c 6553e0d2  05a5c2d8  AcroRd32_653a0000!DllCanUnloadNow+0x150521

如上所说，即在6553e0d2中释放，利用ida分析该函数。根据FreeHeap的kv情况，可以得到释放函数为对象的一个虚函数，如图所示

6553e82b             je      AcroRd32_653a0000!DllCanUnloadNow+0x150567 (6553e88e)
6553e82d 8d45f0          lea     eax,[ebp-10h]
6553e830               push    eax
6553e831 8d4e1c          lea     ecx,[esi+1Ch]
6553e834 e8e607f5ff      call    AcroRd32_653a0000!DllCanUnloadNow+0xa0cf8 (6548f01f)
6553e839 ffb6d4020000    push    dword ptr [esi+2D4h]
6553e83f 897dfc          mov     dword ptr [ebp-],edi
6553e842 ff96d0020000    call    dword ptr [esi+2D0h]

如图，esi为被攻击的函数对象的虚表指针。函数流程为[esi+2D0h] ，其中eax为另一个对象虚表指针。根据poc可得，该函数为addButtonFunc()函数，

　　v:重写被释放对象的地址空间

　　　　通过下断点分别查看在6553e0cc，6553e857，crash时对象的情况，可以得出，填充在调用6553e857之后，crash之前，如下：

//断在6553e00c时
:> dd 5c473d0
05c473d0  65f607a4  65f6077c
05c473e0   65f6073c  65f60728
05c473f0  05c66420   

//断在6553e857时
:> dd 5c473d0
05c473d0  65f607a4  65f6077c
05c473e0   65f6073c  65f60728
05c473f0   05c66420   

//crash时
05c473d0  0c0c08a8
05c473e0
05c473f0      

　　vi:理解漏洞的根本原因

　　　　仔细分析调用流程，函数流程为[esi+2D0h]-->6553f409-->[eax+16]->，在6553f995处下断点，可得，其中eax为esi的虚表指针，而esi为一个对象的首地址，即在对象被释放前先生成了一个新对象。

赋值语句如下

.text:6019F595                 lea     eax, [esi+8Ch]
.text:6019F59B                 mov     ecx, [eax]

查看esi对象的堆的情况，如下。

:> !heap -p -a esi
    address 059fef10 found in
    _HEAP @ 10a0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        059fef08    []   059fef10    000fc - (busy)
          ? AcroRd32_653a0000!CTJPEGDecoderCreateUsingData+28779c

在05ae857设置断点，可看到释放对象在生成的对象为参数，且参数中含有对释放对象的引用，只要对该对象进行应用就可以产生UAF漏洞了。

　　vii:总结

　　　　创建一个父对象，poc所示为ToolButton，然后设置一个函数，函数创建一个子对象，子对象设置函数，对父对象进行删除，且保留了对父对象的引用，对子对象函数进行调用，即可产生UAF漏洞。