Reading Time: 4 minutes
Introduction
Microsoft mitigated many traditional kernel information leaks starting with Windows 11/Windows Server 2022 24H2, including calls such as NtQuerySystemInformation() (when used with the SystemModuleInformation class), by suppressing kernel base addresses unless the caller had the SeDebugPrivilege , typically reserved for administrative processes. That change effectively neutered one of the most accessible KASLR bypass techniques, and, without knowledge of the kernel’s base addresses, exploitation became harder.
While doing patch analysis for CVE-2024-43511, I realised that Microsoft made a mistake leading to a kernel address leak vulnerability. This new bug requires winning a race condition to read out the address; however, it’s pretty easy to achieve. It provides a powerful kernel address leak for any token handle, which can be easily chained with other vulnerabilities to obtain a complete exploit on the latest version of the system.
Vulnerability
Quick review on the patch for CVE-2024-43511
In October 2024, Microsoft released a patch for a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in the Windows kernel, namely CVE-2024-43511.
To fix the issue, when passing parameters to the RtlSidHashInitialize() function, it reads data from a kernel pointer (which is a member of the TOKEN structure), instead of the value set in a user-controlled buffer.
Spotting the bug
With the new update, the RtlSidHashInitialize() function, which performs hash initialisation, now takes as its first parameter a pointer from the TOKEN structure and as its third parameter a user-controlled buffer. Then, RtlSidHashInitialize() stores the first parameter (which is a pointer to the UserAndGroups field of the TOKEN structure) into the third parameter (user-supplied pointer), and starts doing hash initialisation later on:
... continue reading