From patches to POC cve-2015-0003 (2015.3)

From Patch to POC cve-2015-0003

1. Introduction

the vulnerability is due to Windows of the Win32k.sys module is not fully validated for user layer parameters, resulting in null pointer dereference (Null Pointer dereference) the problem.

An attacker can implement privilege elevation by enabling effective exploitation of the vulnerability.

the affected systems include (32bit & Bit) :

Windows Server 2003

Windows Vista

Windows Server 2008

Windows 7

Windows 8 & Windows 8.1

Windows Server 2012

Test environment:

Win7 32bit

the next face is constructed by patch contrast POC and the cause of the vulnerability is simply explained.

2. Patch Comparison

2.1 First Glimpse

Use IDA of the Bindiff plug-in gets Win32k.sys the function comparison before and after the patch is as follows:

In combination with Microsoft's description of the vulnerability, it is possible to know about window handlers. findsystemtimer function patch before and after the difference is large, plus xxxdispatchmessage and Findsystemtimer There is a reason to suspect that the Findsystemtimer function and the vulnerability are related to the presence of a call relationship . The following is a simple analysis of these two functions.

2.2 a little closer.

Xxxdispatchmessage

Use Bindiff look at the difference between this function before and after the patch, you can find the patch after it calls the Findsystemtimer A parameter is passed more than one time.

Findsystemtimer

before and after patches Findsystemtimer functions vary greatly.

before the patch, findsystemtimer and by verifying that it will return to the current PTMR null

after the patch, Findsystemtimer requires two parameters, PMSG and the pWnd . Functions still look the same, all of which are traversed by PTMR, but more variables need to be validated:pmsg->wparam and ptmr- >id,pWnd and ptmr->spwnd.

Currently, we can know the function Findsystemtimer is a big suspect, hWnd and the WParam may be related to the vulnerability.

3. Construction POC

3.1 a path

xxxdispatchmessage findsystemtimer xxxdispatchmessage is the kernel function, can find a path control at the user level xxxdispatchmessage arrives call findsystemtimer poc

Microsoft's use of Hungarian nomenclature for functions is very helpful for analysis, and kernel functions Xxxdispatchmessage can be naturally associated with the user layer DispatchMessage function. The dispatchmessage function appears to be simply a transition of the Dispatchmessageworker function:

and Dispatchmessageworker function will call the kernel's Ntuserdispatchmessage function. the xxxdispatchmessage function is called when the Ntuserdispatchmessage function checks the parameters for some validity . There is such a piece of code in the xxxdispatchmessage function:

0x113 wm_timer message, 0x118 wm_systimer message. When the message to be processed is wm_systimer

wm_systimer for the undisclosed message, fortunately through google query can know its and

so far, we've found a call path at the user level that can eventually invoke a suspicious function Findsystemtimer : DispatchMessage (Wm_systimer) à Dispatchmessageworker à Ntuserdispatchmessage à Xxxdispatchmessage à Findsystemtimer .

3.2 a framework

The above analysis knows that to trigger this vulnerability requires at least one window and can generate Wm_systimer message. Change one of the most basic Win32 windows, and add the following code before the message loop:

with Spy + Observing this window can produce Wm_systimer message:

3.3 Modify

Now you get a window that generates a target message,hWndand theWParamis the two parameters that we need to test, how to make these two parameters randomization is a problem that needs to be solved. Look back to createCaretgenerated when theWm_systimerThe news is interesting because we don't have a loop or a timer, but it producesWm_systimerThe message is time-continuity, and a period of time will send out aWm_systimermessage. So there's reason to suspect that creatingCaretthere is a timer in the function, and it is possible that the timer is issuedWm_systimermessage.

this time again Microsoft's Hungarian nomenclature helped a lot, and sure enough Xxxcreatecaret function found a function that seems to be related to the timer:

Note at this point _setsystemtimer The second parameter is 0xFFFF , which is exactly the same as above Spy + in the output WParam equal, so you can suspect that this parameter represents WParam the value of the. Take advantage of IDA 's xrefs feature to see where all calls to _setsystemtimer are:

Many functions have been tested, including the first CreateCaret , it seems that only Xxxflashwindow The function is reliable: it does not crash, and the associated value can also be changed in the window's message loop. The user layer corresponds to the FlashWindow function, which invokes the _setsystemtimer Context:

Remove Create Caret the part that adds FlashWindow function, modify the previous frame as:

after running, use Spy + to view the output, we expect WParam the value is 0xfff8 .

results show WParam is 0xfff8 , so at this point we have a framework that generates the target message and can modify the relevant values.

3.4 Crash

Finally, use this framework to hWnd and the WParam these two values are randomized and can be added to the message loop of the window:

By putting the entire code on the virtual machine for a period of time, you can get a crash:

at this hwnd=0 , wparam=0xfff8 ( equals the original value ) .

4. Vulnerability Analysis

based on the call stack after the crash, the eax for backtracking, in the function Xxxdispatchmessage in the end can be determined to be a Win32k!tagwnd structure:

so the cause of the loophole is obvious: Findsystemtimer The function does not validate the parameters completely, causing the window handle to be 0 The corresponding kernel object is dereferenced. After patching,thefindsystemtimer function verifies the situation by changing the process so that it does not go into the dereference process.

5. Reference

http://blog.beyondtrust.com/fuzzing-for-ms15-010

From patches to POC cve-2015-0003 (2015.3)