In un’analisi tecnica che ridefinisce i confini della sicurezza offensiva, James Forshaw del team di Google ha pubblicato un aggiornamento critico sulle tecniche exploitation Windows Project Zero, dimostrando come sia possibile manipolare il namespace dell’Object Manager per dilatare le finestre di vulnerabilità temporali. Questa ricerca, focalizzata sulle moderne architetture di Windows 11, rivela come attaccanti sofisticati possano sfruttare meccanismi intrinseci del sistema operativo per trasformare impercettibili race condition Windows 11 in opportunità di attacco concrete, estendendo i tempi di lookup delle risorse da pochi microsecondi a diversi minuti. L’indagine approfondisce metodi avanzati come l’uso di shadow directory e collisioni hash per degradare le performance del kernel senza lasciare tracce permanenti, evidenziando una superficie di attacco che Microsoft ha scelto di non mitigare strutturalmente per preservare l’efficienza globale del sistema.
Cosa leggere
La sfida del tempo: dai microsecondi ai minuti
Il cuore della ricerca risiede nella manipolazione del tempo, una risorsa critica quando si tenta di sfruttare vulnerabilità di tipo race condition. In uno scenario standard, un processo kernel verifica la sicurezza di una risorsa, ne ottiene l’accesso e infine esegue un’azione. L’attaccante deve riuscire ad alterare lo stato del sistema esattamente nell’intervallo tra questi passaggi. Tuttavia, su hardware moderni, questa finestra è incredibilmente stretta. Utilizzando un Surface Pro 11 con Snapdragon X Elite, Forshaw ha misurato che un lookup di base per un evento nominato richiede appena 2 microsecondi. Una velocità tale rende l’exploitation manuale praticamente impossibile, costringendo i ricercatori a cercare metodi per rallentare artificialmente il processo di risoluzione dei percorsi all’interno dell’Object Manager Namespace (OMNS).
Per superare questo ostacolo, l’analisi esplora come la complessità dei percorsi (path) influenzi le prestazioni. È stato osservato che la lunghezza del percorso scala linearmente con il tempo di risoluzione: un path di 32.000 caratteri, vicino al limite strutturale imposto dalla struttura UNICODE_STRING di 65.535 caratteri, impiega circa 35 microsecondi per essere processato. Tuttavia, la vera degradazione delle performance si ottiene aumentando la profondità della directory. Creando una struttura ricorsiva profonda fino a 16.000 livelli, il tempo di lookup sale a 1.300 microsecondi. Sebbene il kernel riesca a gestire la creazione degli handle necessari entro i limiti del pool di memoria, questa tecnica da sola offre solo un vantaggio marginale. La vera svolta arriva combinando la profondità delle directory con meccanismi di rianalisi come i collegamenti simbolici.
Amplificazione tramite Symlink e Reparsing
L’introduzione dei symbolic link nell’equazione permette di moltiplicare esponenzialmente i ritardi. Quando il kernel incontra un collegamento simbolico durante la risoluzione di un percorso, deve riavviare il processo di lookup dal target del link. Per prevenire loop infiniti che potrebbero bloccare il sistema, Windows impone un limite rigido di 64 operazioni di “reparse”. Sfruttando questo limite al massimo, Forshaw ha dimostrato che una catena di 64 link, combinata con le 16.000 directory ricorsive precedentemente descritte, può portare il tempo di risoluzione a circa 4,5 millisecondi.
Questa tecnica richiede una configurazione meticolosa, in cui vengono creati link sequenziali che puntano a se stessi o a directory precedenti in cicli controllati. Utilizzando funzioni native come NtCreateSymbolicLinkObject, è possibile costruire queste catene mantenendo la stabilità del sistema, a patto di gestire correttamente la chiusura degli handle per evitare memory leak. La versatilità di questo approccio è notevole, poiché si applica non solo agli eventi, ma anche ad altre risorse gestite dall’Object Manager, come le chiavi di registro e i file system tramite i punti di montaggio NTFS. Tuttavia, anche 4,5 millisecondi possono risultare insufficienti per attacchi complessi che richiedono interazioni umane o latenze di rete. Per raggiungere ritardi nell’ordine dei minuti, è necessario attaccare le strutture dati fondamentali del kernel.
Attacco algoritmico: collisioni Hash e Shadow Directory
Uno dei metodi più raffinati descritti nell’analisi riguarda lo sfruttamento delle tabelle hash utilizzate dalle directory OMNS. La struttura _OBJECT_DIRECTORY utilizza 37 bucket per indicizzare gli oggetti e la funzione hash processa i caratteri Unicode in modo sequenziale. Forshaw ha identificato pattern di nomi, come “A”, “\0A” e “\0\0A”, che generano deliberatamente collisioni, finendo tutti nello stesso bucket. Questo trasforma la struttura dati da una tabella hash efficiente a una lista lineare lenta. Con 32.000 collisioni forzate, il tempo di lookup per una singola directory sale a 100 microsecondi, e il tempo di inserimento cresce quadraticamente, richiedendo fino a 2,5 secondi. Sebbene efficace su singole directory, questa tecnica soffre di problemi di scalabilità dovuti ai limiti di memoria del pool kernel.
La vera innovazione, definita come un “breakthrough” nella ricerca del 2025, è l’utilizzo delle shadow directory. Questa funzionalità poco nota permette di sovrapporre due directory in modo che i percorsi non risolti nella prima vengano cercati nella seconda (shadow). Configurando nomi per un matching parziale che fallisce deliberatamente, è possibile forzare il kernel a eseguire un traversamento virtuale che simula una profondità di 16.000 livelli utilizzando solo due oggetti reali.
static double RunTest(const wstring name, int iterations,
wstring create_name = L"", HANDLE root = nullptr) {
if (create_name.empty()) {
create_name = name;
}
ScopedHandle event_handle = CreateEvent(create_name, root);
ObjectAttributes obja(name);
vector<ScopedHandle> handles;
Timer timer;
for (int i = 0; i < iterations; ++i) {
HANDLE open_handle;
Check(NtOpenEvent(&open_handle, MAXIMUM_ALLOWED, &obja));
handles.emplace_back(open_handle);
}
return timer.GetTime(iterations);
}
Utilizzando NtCreateDirectoryObject con i flag appropriati e combinando questa tecnica con le collisioni hash e il limite di reparse dei symlink, i risultati sono sconcertanti: su architettura ARM64 si raggiungono ritardi fino a 3 minuti, mentre su workstation basate su processori Intel Xeon, il ritardo può estendersi fino a 19 minuti.
Implicazioni per la sicurezza e assenza di patch
La capacità di bloccare un’operazione di lookup per diversi minuti trasforma vulnerabilità teoriche in vettori di attacco affidabili. Se una race condition non può essere vinta con una finestra di tre minuti, è probabile che sia intrinsecamente non sfruttabile. Queste tecniche forniscono primitive potenti per l’escalation dei privilegi, permettendo agli attaccanti di alterare permessi, file o configurazioni di registro mentre il sistema di sicurezza è “congelato” in fase di verifica. L’applicabilità si estende ben oltre gli eventi di sistema; ad esempio, puntando un mount point NTFS a un percorso lento, l’apertura di un file può essere bloccata per un tempo arbitrario.
Nonostante la gravità delle implicazioni, Microsoft non ha implementato mitigazioni strutturali negli ultimi otto anni. La motivazione risiede nel trade-off tra sicurezza e prestazioni: introdurre controlli aggiuntivi per prevenire questi casi patologici degraderebbe le performance generali del sistema operativo per tutti gli utenti. Di conseguenza, la responsabilità ricade sugli sviluppatori di driver e servizi, che devono condurre audit rigorosi del codice, verificare l’atomicità delle operazioni e utilizzare lock appropriati. James Forshaw Project Zero ha reso disponibile il codice sorgente per replicare questi setup, invitando la comunità di sicurezza a studiare queste meccaniche. La lezione è chiara: su Windows, la complessità del namespace dell’Object Manager è un’arma a doppio taglio che, se compresa a fondo, offre un controllo quasi totale sul flusso temporale delle operazioni kernel.
“Approfondimento sulle Race Condition e TOCTOU”
FAQ
Quali sono le nuove tecniche exploitation Windows Project Zero scoperte da James Forshaw?
Le tecniche principali coinvolgono la manipolazione dell’Object Manager Namespace tramite directory ricorsive profonde, catene di collegamenti simbolici (symlink) per forzare il reparse, collisioni hash deliberate nelle directory e l’uso di shadow directory per simulare profondità virtuali.
Quanto tempo è possibile guadagnare sfruttando queste race condition su Windows 11?
Combinando le shadow directory con le collisioni hash e i symlink, è possibile estendere il tempo di lookup di una risorsa dai normali 2 microsecondi fino a circa 3 minuti su hardware moderno ARM64, e fino a 19 minuti su workstation Xeon.
Perché Microsoft non ha patchato queste vulnerabilità del kernel?
Microsoft non ha implementato mitigazioni specifiche perché queste tecniche sfruttano comportamenti architetturali del sistema. Modificare il funzionamento del lookup nell’Object Manager per prevenire questi casi estremi avrebbe un impatto negativo significativo sulle performance generali di Windows per tutti gli utenti.
Cosa sono le shadow directory e come vengono usate nell’exploitation?
Le shadow directory sono una funzionalità che permette di collegare due directory in modo che, se un oggetto non viene trovato nella prima, la ricerca continua nella seconda. Gli attaccanti le usano per creare loop di ricerca virtuali che consumano enormi quantità di tempo CPU senza richiedere la creazione di migliaia di directory reali.
