Analysis of Critical Vulnerability in Microsoft Windows: Full System Control and Threat to Web3 Security

Last month, Microsoft released a security patch that fixed a Windows system privilege escalation vulnerability being exploited by hackers. This vulnerability mainly exists in earlier versions of Windows and cannot be triggered on Windows 11.

This type of underlying vulnerability in Windows systems has existed for a long time. This article will analyze how hackers may continue to exploit this vulnerability against the backdrop of continually strengthening security defenses. Our analysis environment is Windows Server 2016.

This vulnerability is classified as a zero-day vulnerability, which means it is undisclosed and unpatched. Once a zero-day vulnerability is discovered, it can be maliciously exploited without the user's knowledge, posing a significant threat. Through this Windows system vulnerability, hackers can gain complete control of the system.

The consequences of being hacked and having a system compromised are severe, including personal information theft, system crashes, data loss, financial losses, and the implantation of malware. For individual users, cryptocurrency private keys may be stolen, and digital assets may be transferred. On a larger scale, this vulnerability could threaten Web3 projects that rely on Web2 infrastructure to operate.

Analyzing the patch code, the problem seems to be that the reference count of an object has been processed one time too many. According to earlier comments in the win32k source code, the original code only locked the window object and did not lock the menu object within the window object, which could lead to the menu object being incorrectly referenced.

During the implementation of the vulnerability proof of concept ( PoC ), we found that there was an issue in the handling of the menu object in the xxxEnableMenuItem function. The returned menu could be the main window menu, a submenu, or even a sub-submenu. We constructed a special four-layer menu structure to trigger the vulnerability.

Before building the (Exp) exploit, we mainly considered two directions: executing shellcode and modifying the token address using read/write primitives. Considering feasibility, we chose the latter. The entire exploitation process is divided into two steps: exploiting the UAF vulnerability to control the cbwndextra value, and then establishing stable read/write primitives.

To achieve the first data write, we utilize the window name object in the window class WNDClass to occupy the released menu object. By carefully constructing the memory layout, we can control the memory data of adjacent objects, thus modifying the cb-extra value of HWNDClass.

We designed a memory layout for three consecutive HWND objects, occupying the space of the intermediate object with an HWNDClass object after releasing it. The previous HWND object is used for function verification, while the latter is used for final read and write primitives. By leaking the kernel handle address, we can precisely control the order of object arrangement.

In terms of reading and writing primitives, we use GetMenuBarInfo() to achieve arbitrary read, and SetClassLongPtr() to achieve arbitrary write. Except for token writing, other writes utilize the class object offset of the first window object.

Overall, although the Windows 11 preview version has started to refactor the win32k code with Rust, such vulnerabilities still pose security risks for older systems. The exploitation process is relatively simple, mainly relying on the leakage of desktop heap handle addresses. The discovery of this vulnerability may benefit from improved code coverage detection. For vulnerability detection, in addition to focusing on the key points of the triggering functions, attention should also be paid to abnormal memory layouts and data read/write operations.