Windows VDM Zero Page Race Condition Privilege Escalation Release Date: April 10, 2007 Date Reported: December 12, 2006 Severity: Medium (Local Privilege Escalation to Kernel) Systems Affected: Windows NT 4.0 SP6 Windows 2000 SP4 Windows XP SP2 (x86) Windows Server 2003 SP2 (x86) Overview: eEye Digital Security has discovered a local privilege escalation vulnerability in the Windows kernel that allows an unprivileged user with the ability to execute a program to fully compromise an affected system. All x86 versions of Windows up to and including Windows Server 2003 SP2 are vulnerable. The Windows kernel's Virtual DOS Machine (VDM) implementation features a race condition through which a malicious program can modify the first 4KB page of physical memory (also known as the "zero page"). The data in this region of memory is trusted and may be subsequently used by other Virtual DOS Machines, including a VDM instantiated by the Windows kernel as part of hibernating or effecting a blue-screen crash. Exploitation of this vulnerability therefore allows arbitrary code to run within other users' VDM processes, and even within the kernel if hibernation or a blue-screen can be provoked by any available means. This vulnerability was silently fixed within Windows Vista in June 2006 or earlier. Technical Details: As part of VDM initialization, NT!VdmpInitialize (invoked by calling NtVdmControl(3)) copies the contents of the zero page to virtual address 0, so that the VDM can have a duplicate of the system's original Interrupt Vector Table (IVT) and BIOS data area. To accomplish this, VdmpInitialize opens "DevicePhysicalMemory" with SECTION_ALL_ACCESS, then maps a view of the first 4KB of the section. What happens next is a memmove from this view to virtual address 0, wrapped in an exception handler which will unmap the view and abort the function in the event of an exception; the view is also immediately unmapped if the memmove completes successfully. Regrettably, the physical memory view is mapped with PAGE_READWRITE memory permissions into the user-mode portion of the address space, so a malicious thread may be able to regain execution before the view is unmapped, and then directly modify the zero page by writing into the view. Although the window of opportunity presented by the race condition is brief, the base address of the mapping is dynamic, and VdmpInitialize can only successfully execute once per process, it is nevertheless possible to quickly and reliably exploit this vulnerability. Working out the details, however, is left as an exercise for the reader. Just kidding. By creating a number of high-priority, CPU-bound threads within the NTVDM process, the chances of preempting the VdmpInitialize thread while the view is available (for instance, when virtual page 0 is first touched, or during the call to ZwUnmapViewOfSection) increase greatly. As for the address of the view, it can be corralled to the point of predictability by filling the virtual address space of the process, with the exclusion of one hole which the CPU-bound "writer" threads will repeatedly target. And while it is true that VdmpInitialize can only succeed once per process, it can fail endlessly, each time mapping and attempting to duplicate the zero page. If there is no writable memory at virtual address 0 when VdmpInitialize calls memmove, an access violation occurs and the function fails. (Note that this trick does not apply to NT 4.0, as the exception is unhandled and will result in a blue-screen.) Code executing in Virtual-8086 mode within a VDM may call software interrupts from the IVT at will; the most interesting example is within the VDM established by HAL.DLL!HalpBiosDisplayReset. Here, HalpBiosCall is invoked to transfer execution to HalpRealModeStart, which is simply the instructions "MOV EAX, 12h / INT 10h" followed by a VDM "BOP." The physical page of HAL.DLL containing this code is mapped at virtual address 20000h with write permissions, and therefore the INT 10h handler may patch code within HAL.DLL (for instance, HalpRealModeEnd) in order to transcend V86 mode and infiltrate the kernel directly. (It is also worth noting that the V86-mode code necessarily executes with EFlags.IOPL set to 3.) Although the kernel is currently only known to use BIOS interrupts in the event of hibernation or a blue-screen (via InbvResetDisplay), this vulnerability does thereby enable what would otherwise be a local denial-of-service to become a local elevation of privileges. On Windows NT 4.0, which does not support the OBJ_KERNEL_HANDLE ObjectAttributes flag, a second race condition exists wherein the temporary "DevicePhysicalMemory" section handle opened during VdmpInitialize may be abused by an unprivileged program, allowing write access to the entirety of physical memory. Protection: Retina - Network Security Scanner has been updated to identify this vulnerability. Vendor Status: Microsoft has released a patch for this vulnerability. The patch is available at: http://www.microsoft.com/technet/security/bulletin/MS07-022.mspx Credit: Derek Soeder Related Links: eEye Research - http://research.eeye.com Retina - Network Security Scanner - Free Trial: http://www.eeye.com/html/products/retina/download/index.html Blink - Unified Client Security Personal - Free For Personal Use For One Year: http://www.eeye.com/html/products/blink/personal/download/index.html Blink - Unified Client Security Professional - Free Trial: http://www.eeye.com/html/products/blink/download/index.html Blink - Unified Client Security Neighborhood Watch - Free For Personal Use: http://www.eeye.com/html/products/blink/neighborhoodwatch/index.html Greetings: Jim H. RB, SB, MB, SJ, Doc. GLin, CSam, and Tamara Copyright (c) 1998-2007 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please email alert (at) eEye (dot) com [email concealed] for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are no warranties, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.