A very interesting vulnerability in win32kfull.sys on Windows 10 devices up to and including 20H2. Although the exploit in the wild specifically targeted Windows 10 v1709 to Windows 10 v1909, as noted at https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/, the researchers noted that the vulnerability could be modified to work on Windows 20H2 with minor modifications.

From my perspective this is rather significant, particularly given this is a win32kfull.sys bug we are talking about here. Most of the primitives that made win32k exploitation easier were entirely wiped out by Microsoft which prompted a lot of researchers who previously spoke publicly about such primitives in conference talks and similar to go quiet. Whilst rumor has been that there were other primitives one could use for exploitation, they were considered closely guarded secrets due to the difficulty in finding them and the fact that Microsoft would be likely to patch them very quickly.

The new primitive that is used here appears to be setting tagMenuBarInfo.rcBar.left and tagMenuBarInfo.rcBar.top and then calling GetMenuBarInfo(), which allows one to perform an arbitrary read in kernel memory. This has not been discussed before but is similar to another concepted discussed in the paper “LPE vulnerabilities exploitation on Windows 10 Anniversary Update” at ZeroNights which mentioned using two adjacent Windows and then setting the cbwndExtra field of the first window to a large value to allow the first window to set all of the properties of the second window. By chaining this together the attacker could achieve an arbitrary read and write in kernel memory.

The bug itself stems from a xxxClientAllocWindowClassExtraBytes() callback within win32kfull!xxxCreateWindowEx. Specifically when xxxCreateWindowEx() creates a window object with a cbwndExtra field set, aka it has extra Window bytes, it will perform a xxxClientAllocWindowClassExtraBytes() callback to usermode to allocate the extra bytes for the Window.

You may be wondering why such callbacks are needed. Well a long time ago Windows used to handle all its graphics stuff in kernel mode, but then people realized that was too slow given increasing demands for speed, so they made most of the code operate in usermode with key stuff handled by kernel mode. This lead to a big rift and is the reason we have callbacks. Thats the nutshell version anyway but go read up on http://mista.nu/research/mandt-win32k-slides.pdf and https://media.blackhat.com/bh-us-11/Mandt/BH_US_11_Mandt_win32k_WP.pdf if you want to learn more. Its a fascinating read :)

Anyway back on topic. Since xxxClientAllocWindowClassExtraBytes() is a callback that is under the attackers controller, the attacker can set a hook that will trigger when a xxxClientAllocWindowClassExtraBytes() callback is made and call NtUserConsoleControl() with the handle of the window that is currently being operated on. This will end up calling xxxConsoleControl() in kernel mode which will set *((tagWND+0x28)+0x128) to an offset, and will AND the flag at *((tagWND+0x28) + 0xE8) with 0x800 to indicate that the value of the WndExtra member is an offset from the base address of RtlHeapBase. Unfortunately, whatever value is returned by the hooked xxxClientAllocWindowClassExtraBytes() callback (aka whatever value the attacker chooses) will be used as the value of WndExtra, since remember we are meant to be allocating the address of this field at the time due to the earlier xxxCreateWindowEx() call needing to allocate memory for WndExtra.

Once this is done, the callback will be completed, execution will return to usermode, and a call to DestroyWindow() will be made from usermode. This will cause xxxDestroyWindow() to be called in kernel mode which will call xxxFreeWindow(), which will check if *((tagWND+0x28) + 0xE8) has the flag designated by 0x800 set, which it will due to the alterations made by xxxConsoleControl(). This will then result in a call to RtlFreeHeap() which will attempt to free an address designated by RtlHeapBase + offset, where offset is the value of WndExtra (which is taken from the xxxClientAllocWindowClassExtraBytes() callback and therefore completely controlled by the attacker).

This subsequently results in the attacker being able to free memory at an arbitrary address in memory.

I’ll not dive into a full detailed analysis of the rest of the exploitation steps as the article at https://ti.dbappsecurity.com.cn/blog/index.php/2021/02/10/windows-kernel-zero-day-exploit-is-used-by-bitter-apt-in-targeted-attack/ is very comprehensive but I will say from what I’ve read there, there is enough detail that people of a decent skill level could probably recreate this exploit. It certainly isn’t an easy exploit to recreate but the exploit goes into a lot of detail about the various mitigation bypasses that were used to make this exploit possible, which could help an attacker more readily recreate this bug.

Again, this exploit was exploited in the wild so it is possible for this bug to be recreated, it just might take some time for people to work out a few of the specifics needed to get a working exploit. If you are running Windows 10, it is highly advised to upgrade as soon as possible: everything I am reading here points to signs that this will be weaponized within the coming few weeks or months.

Additionally it should be noted that this exploit was noted to be capable of escaping Microsoft IE’s sandbox (but not Google Chrome’s) so if you are running Microsoft IE within your environment, its even more imperative that you patch this issue to prevent an attacker from combining this with an IE 0day and conducting a drive by attack against your organization, whereby simply browsing a website could lead to attackers gaining SYSTEM level privileges against affected systems.