karollooool/cve-2026-50416-writeup-and-pocCVE-2026-50416: Windows 11 KASLR-Umgehung
Auf dem betroffenen System lieferte dieses Lesen aus dem User-Mapping des Win32-Desktop-Heaps eine Kernel-Adresse zurück:
ULONG64 leaked = *(ULONG64 *)(desktop_heap + 0x100);
Das ist die gesamte Offenlegung. Zunächst war es nur ein acht Byte großer Wert mit überzeugenden hohen Bits. Ich habe mehr Zeit damit verbracht zu prüfen, worauf der Wert folgte, als ihn zu lesen.
Microsoft veröffentlichte das Problem als CVE-2026-50416, eine Win32k-Offenlegung von Informationen, klassifiziert als CWE-200.
Der PoC beginnt am x64-TEB. GS:[0x30] liefert den aktuellen TEB, TEB + 0x800 erreicht die Win32-Client-Daten in dem von mir getesteten Build, und Slot 5 enthält die Benutzeradresse des Desktop-Heaps:
PVOID teb = (PVOID)__readgsqword(0x30);
PVOID *client_info = (PVOID *)((BYTE *)teb + 0x800);
BYTE *desktop_heap = (BYTE *)client_info[5];
Slot 5 sind weitere 0x28 Bytes in diesen Client-Daten. Trellix dokumentierte denselben TEB + 0x800 + 0x28-Pfad bei der Untersuchung von tagWND-Mappings unter Windows 10 1909. Diese Offsets sind keine ABI. Ich habe sie fest codiert und rufe VirtualQuery auf das Ergebnis auf, bevor ich die gemappte Region verwende.
Die Pointer-Prüfung deckt die kanonische x64-Vorzeichenerweiterung, die Acht-Byte-Ausrichtung und bekannte Sentinel-Muster ab. Der Wert muss anschließend die untenstehenden Verhaltenstests bestehen.
Der Haupt-PoC liest Offset 0x100, erstellt ein STATIC-, ein BUTTON- und ein EDIT-Fenster, liest ihn erneut, zerstört die drei Fenster und liest ihn dann noch einmal.
ULONG64 before = *(ULONG64 *)(desktop_heap + 0x100);
/* Create STATIC, BUTTON and EDIT windows. */
ULONG64 after_create = *(ULONG64 *)(desktop_heap + 0x100);
/* Destroy all three. */
ULONG64 after_destroy = *(ULONG64 *)(desktop_heap + 0x100);
Die drei QWORDs stimmten überein. Diese Fensterzuweisungen kamen und gingen; der Wert bei 0x100 blieb unverändert.
kaslr_sandbox_proof.c übernimmt den Prozessvergleich. Der Elternprozess leitet die Standardausgabe jedes Kindprozesses über eine Pipe um, parst das vom Kindprozess gelesene QWORD und vergleicht es mit dem Basiswert.
Kindprozesse, die an den Standarddesktop angehängt waren, gaben denselben Wert zurück. Ein Kindprozess, der einem mit CreateDesktop erstellten Desktop zugewiesen wurde, gab einen anderen Wert zurück. Die Testumgebung prüft außerdem Kindprozesse mit Low-Integrität, AppContainer, dessen LPAC-Konfiguration sowie Low-Integritäts-AppContainer. Sie alle führen das Lesen aus ihrem eigenen TEB und Mapping durch, anstatt den Wert des Elternprozesses zu erhalten.
supporting_proof_no_window.c führt das Lesen durch, ohne CreateWindowEx aufzurufen. Es wird kein neues USER-Fenster benötigt.
Der Haupt-PoC behandelt den geleakten Wert minus 0x40 als die kernel-seitige Basis, die dem Desktop-Heap entspricht:
ULONG64 candidate_kernel_heap_base = leaked - 0x40;
Anschließend schlägt es user32!gSharedInfo nach, verwendet die unteren 16 Bits eines HWND als Index in die USER-Handle-Tabelle und schreitet durch aheList um HeEntrySize voran. Wenn das erste QWORD in diesem Eintrag ungleich null und kleiner als der gemappte Heap ist, verwendet der PoC es als relativen Desktop-Heap-Offset:
ULONG index = (ULONG)(ULONG_PTR)hwnd & 0xffff;
BYTE *entry = (BYTE *)shared->aheList + index * shared->HeEntrySize;
ULONG64 heap_offset = *(ULONG64 *)entry;
if (heap_offset > 0 && heap_offset < heap_size) {
BYTE *user_candidate = desktop_heap + heap_offset;
ULONG64 kernel_candidate = candidate_kernel_heap_base + heap_offset;
}
Dies ist dieselbe allgemeine Beziehung, die in älteren Desktop-Heap-Techniken verwendet wird: Die Benutzer- und Kernel-Sichten platzieren ein Objekt am selben Offset von ihren jeweiligen Heap-Basen. Unit 42 liefert nützlichen Hintergrund zur USER-Handle-Tabelle und den älteren Adresslecks über gSharedInfo und HMValidateHandle.
Die resultierenden Adressen sind die Kernel-Objekt-Kandidaten des PoC. Die 0x40-Beziehung, das Layout der Handle-Einträge und die TEB-Offsets gehören zu dem Build, der für den Test verwendet wurde.
Ich belasse die Objekt-Kandidaten dort. Das QWORD bei desktop_heap + 0x100 ist bereits stabile Kernel-Space-Adressinformation in einem benutzerlesbaren Mapping. Ein separater Win32k-Speicherkorruptionsfehler kann es anstelle einer Adressschätzung verwenden.