Microsoft 0day Vulnerability Analysis: Potential Major Threat to Web3 Infrastructure

Last month, a security patch from Microsoft included a publicly exploited elevation of privilege vulnerability in win32k. This vulnerability appears to only exist in earlier Windows systems and cannot be triggered on Windows 11.

The exploitation of such vulnerabilities has a long history. This article will analyze how attackers may continue to exploit this vulnerability in the context of the current ongoing improvements in mitigation measures. We completed the entire analysis process in a Windows Server 2016 environment.

A 0-day vulnerability refers to a flaw that has not been disclosed or patched, which can be exploited by malicious actors without detection, posing significant destructive potential. The recently discovered 0-day vulnerability resides at the Windows system level, allowing hackers to gain complete control over Windows.

A system controlled by hackers may lead to personal information leaks, system crashes, data loss, financial losses, and the implantation of malware. For Web3 users, private keys may be stolen and digital assets transferred. On a broader scale, this vulnerability could even impact the entire Web3 ecosystem running on Web2 infrastructure.

Patch Analysis

After analyzing the patch, it appears that the issue is simply that the reference count of an object was processed one time too many. Because the win32k code is relatively old, we can find some early source code comments indicating that the previous code only locked the window object, without locking the menu object within the window object, which may have been incorrectly referenced.

Proof of Concept for Exploit ( PoC )

We found that the menu passed into xxxEnableMenuItem() is usually locked in the upper-level function. Further analysis reveals that the menus returned by the MenuItemState function in xxxEnableMenuItem can be of two types: the main menu of the window or a submenu in the menu(, or even a submenu of the submenu).

In PoC, we constructed a special four-layer menu structure and set specific properties for each level of the menu to perform detection and judgment through the xxxEnableMenuItem function. Key steps include removing certain menu reference relationships and releasing specific menu objects when xxxRedrawTitle returns to the user layer.

Exploiting Vulnerabilities ( Exp ) Implementation

Overall Idea

We mainly considered two types of exploitation directions: executing shellcode and modifying the token address using read-write primitives. Taking various factors into account, we chose the latter.

The entire exp can be divided into two key issues: how to exploit the UAF vulnerability to control the value of cbwndextra, and how to achieve stable read and write primitives after controlling the value of cbwndextra.

Implement the first data write

We use the window name object in the window class WNDClass to occupy and release the menu object. The key is to find a location in the address structure that we can build where data can be written arbitrarily.

Finally, we chose to implement the write operation using a flag AND 2 in the xxxRedrawWindow function. We write to the cb-extra of HWNDClass instead of the cb-extra of the window object to better control the memory layout.

stable memory layout

We designed a memory layout of at least three consecutive 0x250 byte HWND objects, releasing the middle one and occupying it with a 0x250 byte HWNDClass object. The HWND objects at the front and back are used to verify parameters and as a medium for read and write primitives.

We accurately determine whether the requested window object is arranged as expected by examining the leaked kernel handle address in the heap memory.

Modification of read/write primitives

We use GetMenuBarInfo() to achieve arbitrary read and SetClassLongPtr() to achieve arbitrary write. Except for the write operation that replaces TOKEN, other writes are completed using the offset of the class object of the first window object.

Summary

1. Although the win32k vulnerability has existed for a long time, Microsoft is attempting to restructure the related kernel code using Rust, and such vulnerabilities may be eliminated in future new systems.

2. The exploitation process this time is relatively simple, with the main difficulty being how to control the first write. The vulnerability still heavily relies on the leakage of the desktop heap handle address, which remains a security risk for older systems.

3. The discovery of this vulnerability may benefit from more comprehensive code coverage testing.

4. For vulnerability exploitation detection, in addition to focusing on the key points of the vulnerability trigger functions, it is also important to specifically detect abnormal memory layouts and window data read and write operations.