karollooool/cve-2026-50416-writeup-and-pocCVE-2026-50416: contournement du KASLR sous Windows 11
Sur le système affecté, cette lecture depuis le mappage utilisateur du tas du bureau Win32 renvoyait une adresse du noyau :
ULONG64 leaked = *(ULONG64 *)(desktop_heap + 0x100);
C'est toute la divulgation. Au départ, ce n'était qu'une valeur de huit octets avec des bits de poids fort convaincants. J'ai passé plus de temps à vérifier ce que la valeur suivait qu'à la lire.
Microsoft a publié le problème sous CVE-2026-50416, une divulgation d'informations Win32k classée CWE-200.
Le PoC commence au TEB x64. GS:[0x30] donne le TEB courant, TEB + 0x800 atteint les données client Win32 dans la build que j'ai testée, et l'emplacement 5 contient l'adresse utilisateur du tas de bureau :
PVOID teb = (PVOID)__readgsqword(0x30);
PVOID *client_info = (PVOID *)((BYTE *)teb + 0x800);
BYTE *desktop_heap = (BYTE *)client_info[5];
Le slot 5 se trouve à nouveau à 0x28 octets dans ces données client. Trellix a documenté la même route TEB + 0x800 + 0x28 en étudiant les mappages tagWND sur Windows 10 1909. Ces offsets ne constituent pas une ABI. Je les ai codés en dur et j'appelle VirtualQuery sur le résultat avant d'utiliser la région mappée.
La vérification du pointeur couvre l'extension de signe canonique x64, l'alignement sur huit octets et les motifs sentinelles connus. La valeur doit ensuite survivre aux tests de comportement ci-dessous.
Le PoC principal lit l'offset 0x100, crée une fenêtre STATIC, une fenêtre BUTTON et une fenêtre EDIT, le relit, détruit les trois fenêtres, puis le relit une dernière fois.
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);
Les trois QWORD correspondaient. Ces allocations de fenêtre sont apparues puis ont disparu ; la valeur à 0x100 n'a pas changé.
kaslr_sandbox_proof.c gère la comparaison des processus. Le parent redirige la sortie standard de chaque enfant via un pipe, analyse le QWORD lu par l'enfant et le compare à la valeur de référence.
Les enfants attachés au bureau par défaut ont renvoyé la même valeur. Un enfant affecté à un bureau créé avec CreateDesktop en a renvoyé une différente. Le harnais exerce également des enfants en intégrité Low, AppContainer, sa configuration LPAC, et AppContainer en intégrité Low. Tous effectuent la lecture depuis leur propre TEB et leur propre mapping plutôt que de recevoir la valeur du parent.
supporting_proof_no_window.c effectue la lecture sans appeler CreateWindowEx. Aucune nouvelle fenêtre USER n'est nécessaire.
Le PoC principal traite la valeur divulguée moins 0x40 comme la base côté noyau correspondant au tas du bureau :
ULONG64 candidate_kernel_heap_base = leaked - 0x40;
Il recherche ensuite user32!gSharedInfo, utilise les 16 bits de poids faible d'un HWND comme index de la table des handles USER, et avance dans aheList de HeEntrySize. Si le premier QWORD de cette entrée est non nul et inférieur au tas mappé, le PoC l'utilise comme décalage relatif dans le tas du bureau :
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;
}
Il s'agit de la même relation générale que celle utilisée dans les techniques plus anciennes de tas de bureau : les vues utilisateur et noyau placent un objet au même décalage par rapport à leurs bases de tas respectives. Unit 42 fournit un contexte utile sur la table de handles USER et les fuites d'adresses plus anciennes gSharedInfo et HMValidateHandle.
Les adresses obtenues constituent les candidats d'objets noyau du PoC. La relation 0x40, la disposition des entrées de handle et les décalages du TEB appartiennent à la build utilisée pour le test.
Je laisse les candidats d'objets à cet endroit. Le QWORD à desktop_heap + 0x100 est déjà une information d'adresse stable en espace noyau dans un mapping lisible par l'utilisateur. Un bug distinct de corruption mémoire dans Win32k peut l'utiliser à la place d'une supposition d'adresse.