New zero-day vulnerability CVE-2019-0859 in win32k.sys

[harlan4096]

In March 2019, our automatic Exploit Prevention (EP) systems detected an attempt to exploit a vulnerability in the Microsoft Windows operating system. Further analysis of this event led to us discovering a zero-day vulnerability in win32k.sys. It was the fifth consecutive exploited Local Privilege Escalation vulnerability in Windows that we have discovered in recent months using our technologies. The previous ones were:

* Zero-day exploit (CVE-2018-8453) used in targeted attacks
* A new exploit for zero-day vulnerability CVE-2018-8589
* Zero-day in Windows Kernel Transaction Manager (CVE-2018-8611)
* The fourth horseman: CVE-2019-0797 vulnerability

On March 17, 2019 we reported our discovery to Microsoft; the company confirmed the vulnerability and assigned it CVE-2019-0859. Microsoft have just released a patch, part of its update, crediting Kaspersky Lab researchers Vasiliy Berdnikov and Boris Larin.

Technical details

CVE-2019-0859 is a Use-After-Free vulnerability that is presented in the CreateWindowEx function. During execution CreateWindowEx sends the message WM_NCCREATE to the window when it’s first created. By using the SetWindowsHookEx function, it is possible to set a custom callback that can handle the WM_NCCREATE message right before calling the window procedure.

In win32k.sys all windows are presented by the tagWND structure which has an “fnid” field also known as Function ID. The field is used to define the class of a window; all windows are divided into classes such as ScrollBar, Menu, Desktop and many others. We have already written about Function ID related bugs.

During the WM_NCCREATE callback, the Function ID of a window is set to 0 and this allowed us to set extra data for the window from inside our hook. More importantly, we were able to change the address for the window procedure that was executed immediately after our hook. The change of window procedure to the menu window procedure leads to the execution of xxxMenuWindowProc and the function initiates Function ID to FNID_MENU because the current message is equal to WM_NCCREATE. But the most important part is that the ability to manipulate extra data prior to setting Function ID to FNID_MENU can force the xxxMenuWindowProc function to stop initialization of the menu and return FALSE. Because of that, sending of the NCCREATE message will be considered a failed operation and CreateWindowEx function will stop execution with a call to FreeWindow. Because our MENU-class window was not actually initialized, it allows us to gain control over the address of the memory block that is freed.

Continue Reading