CVE-2014-4113 Detailed Vulnerability and Patch Analysis

As you might have heard, Microsoft recently patched some vulnerabilities, vulnerabilities related to Sandworm CVE-2014-4114(Powerpoint exploit) and Font parsing vulnerabilitiy (CVE-2014-4148). But in this article, I'm more interested to talk about CVE-2014-4113, local kernel vulnerability that successful exploitation of it would give you SYSTEM access. So I started analyzing Microsoft's Patch (KB3000061) and during analysis, I found a PoC for this vulnerability in wild. So I combined my patch analysis and reverse engineering this PoC binary together to deeply understand this vulnerability and exploitation technique. I'll share it step by step, with all details, so you'll know everything about CVE-2014-4113.

First of all, I downloaded KB3000061 and I noticed that it just does have win32k.sys, so I created two folders called Vulnerableand Patched. I placed proper win32k.sys inside each of them. Next I loaded both of them in IDA and saved both databases. Now it's time to see what's changed in both versions, so I used TurboDiff for this job. TurboDiff simply gives you a text table of changed functions. It gave me 25 changed function. I started checking differences in functions, one of them caught my attention. In internal function of xxxHandleMenuMessages, I noticed patched version does have an additional check for returned value from xxxMNFindWindowFromPoint (internal function). That check was a call to IsMFMWFPWindow function and parameter toIsMFMWFPWindow was exactly return value of xxxMNFindWindowFromPoint. So I figured out there is something was wrong here that Microsoft had to check to see if return value from xxxMNFindWindowFromPoint is valid or not. You can see difference here:

Vulnerable win32k.sys

Patched version:

So looking to this patch from a little zoom back:

Vulnerable:

Patched code:

So knowing this, I was thinking about exploitation method for this vulnerability, how to trigger this vulnerability and makexxxHandleMenuMessages API to call xxxSendMessage to an invalid HANDLE. As soon as I saw that the vulnerability is related to window system and possible NULL value during xxxHandleMenuMessage process, I just remembered this. For exploiting that, you had to map zero/null page, create a fake object at zero page and trigger the vulnerability. So general idea was correct, now I was looking for a way to make this happen, I was thinking about a way to cause xxxHandleMenuMessage deal with a NULL handle. Luckily/lazily I suddenly saw that there is a PoC published online for this vulnerability, so as a known lazy, instead of trying to solve it on my own for practice, I just downloaded the sample and started checking it. Lots of things was as I thought, the only missing part in chain of exploitation was how to make that NULL in xxxHandleMenuMessage. It was done by hooking and altering paramters in user mode, you can read more about these tricks here and here.

So basically the PoC deletes the menu and returns -5, so xxxSendMessage will use a tagwnd object starting from -5 (0xFFFFFFFB) to positive values which is in user-mode. The PoC allocated zero-page using ZwAllocateVirtualMemory with 0x00 as base address and writes a fake tagWND object here. Windows allows zero page allocation for 16-bit application support. So the tagWND object have two important parts, one is WS_EXECUTE_IN_KERNEL flag which is at offset ((BYTE*)&pWnd->state)+0x02.  So by setting 0x16 to 0x04, you are telling kernel that this callback function needs to be executed in kernel. Second important entry in tagWND is at offset 0x60 which holds address of callback function. So as PoC modifies return value by hook and sets value to -5, it should set 0x16 - 0x05 (0x11) equal to 0x04, and 0x60 - 0x05 (0x5B) should hold address of shellcode to be executed in kernel. See:

The shellcode does nothing other than copying system process (pid = 4) token and writing it to current process token, therefore it will have SYSTEM access. Now any process created by this process will have SYSTEM process too. So cmd.exe created by this application will run as SYSTEM too. See:

and zero page looks like this:

Cyan color holds address of shellcode and yellow background holds WS_EXECUTE_IN_KERNEL flag.

For triggering the vulnerability, simply it creates two layer popup menu (one main popup menu and one sub menu to it), then it calls TrackPopupMenu to trigger hook. In hook itself, it replaces window handler function, see:

and new handler function, simply deletes popup menu and returns 0xFFFFFFFB (-5):

So update your OS specially servers before as soon as possible.