CVE-2026-50416: un indirizzo del kernel nell'heap del desktop

Sul sistema interessato, questa lettura dal mapping utente dell'heap del desktop Win32 restituiva un indirizzo del kernel:

ULONG64 leaked = *(ULONG64 *)(desktop_heap + 0x100);

Questa è l'intera divulgazione. All'inizio era solo un valore di otto byte con bit alti convincenti. Ho passato più tempo a verificare cosa seguisse quel valore che a leggerlo.

Microsoft ha pubblicato il problema come CVE-2026-50416, una divulgazione di informazioni in Win32k classificata come CWE-200.

Arrivare alla mappatura

Il PoC parte dal TEB x64. GS:[0x30] fornisce il TEB corrente, TEB + 0x800 raggiunge i dati client Win32 nella build che ho testato, e lo slot 5 contiene l'indirizzo utente dell'heap del desktop:

PVOID teb = (PVOID)__readgsqword(0x30);
PVOID *client_info = (PVOID *)((BYTE *)teb + 0x800);
BYTE *desktop_heap = (BYTE *)client_info[5];

Lo slot 5 è un altro blocco di 0x28 byte all'interno di quei dati del client. Trellix ha documentato la stessa via TEB + 0x800 + 0x28 studiando le mappature tagWND su Windows 10 1909. Questi offset non sono un ABI. Li ho codificati in modo fisso e chiamo VirtualQuery sul risultato prima di utilizzare la regione mappata.

Il controllo del puntatore copre l'estensione del segno canonica x64, l'allineamento a otto byte e i pattern sentinella noti. Il valore deve poi superare i test comportamentali riportati di seguito.

Cosa ho modificato attorno a questo

Il PoC principale legge l'offset 0x100, crea una finestra STATIC, una BUTTON e una EDIT, lo rilegge, distrugge le tre finestre, poi lo legge ancora una volta.

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);

I tre QWORD coincidevano. Quelle allocazioni di finestra andavano e venivano; il valore in 0x100 no.

kaslr_sandbox_proof.c gestisce il confronto tra processi. Il processo padre reindirizza lo stdout di ogni figlio attraverso una pipe, analizza il QWORD letto dal figlio e lo confronta con il valore di riferimento.

I figli collegati al desktop predefinito restituivano lo stesso valore. Un figlio assegnato a un desktop creato con CreateDesktop ne restituiva uno diverso. Il harness esercita anche figli con integrità Low, AppContainer, la sua configurazione LPAC e AppContainer con integrità Low. Tutti eseguono la lettura dal proprio TEB e mapping anziché ricevere il valore dal padre.

supporting_proof_no_window.c esegue la lettura senza chiamare CreateWindowEx. Non è necessaria alcuna nuova finestra USER.

L'aritmetica degli indirizzi

Il PoC principale tratta il valore divulgato meno 0x40 come la base lato kernel corrispondente all'heap del desktop:

ULONG64 candidate_kernel_heap_base = leaked - 0x40;

Poi cerca user32!gSharedInfo, usa i 16 bit bassi di un HWND come indice della tabella degli handle USER e avanza attraverso aheList di HeEntrySize. Se il primo QWORD in quella voce è diverso da zero e inferiore all'heap mappato, il PoC lo usa come offset relativo dell'heap del desktop:

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;
}

Questa è la stessa relazione generale usata nelle vecchie tecniche desktop-heap: le viste utente e kernel collocano un oggetto allo stesso offset dalle rispettive basi dell'heap. Unit 42 fornisce un utile contesto sulla tabella degli handle USER e sulle vecchie fughe di indirizzi gSharedInfo e HMValidateHandle.

Gli indirizzi risultanti sono i candidati oggetto-kernel del PoC. La relazione 0x40, il layout della voce handle e gli offset del TEB appartengono alla build usata per il test.

Lascio lì i candidati oggetto. Il QWORD in desktop_heap + 0x100 è già un'informazione stabile sull'indirizzo in kernel-space all'interno di un mapping leggibile dall'utente. Un bug separato di corruzione della memoria in Win32k può usarlo al posto di una congettura sull'indirizzo.