The Windows IOCTL Census: A Corpus-Scale, Multi-Architecture Database of the Driver Control-Code Surface

Sintesi Tecnica: Il Censimento degli IOCTL di Windows

Problema
Il percorso di controllo dei dispositivi in Windows rappresenta una superficie di attacco critica in cui processi non privilegiati possono raggiungere la memoria del kernel tramite codici di controllo I/O (IOCTL). Le vulnerabilità in questo percorso, come le lunghezze di buffer non controllate, permettono l'escalation dei privilegi. Sebbene la comunità di sicurezza possieda scanner (ad esempio, ScrewedDrivers, POPKORN, ioctlance) che eseguono l'esecuzione simbolica dei driver per trovare vulnerabilità specifiche, e liste curate (ad esempio, LOLDrivers) che tracciano driver noti come dannosi, non esiste una mappa sistematica e persistente della superficie di dispatch dei codici di controllo nell'intero ecosistema dei driver. Gli strumenti simbolici esistenti soffrono di esplosione dei percorsi, alti tassi di falsi negativi e limitazioni architettoniche; in particolare, spesso falliscono sui driver a 32 bit (x86), che costituiscono circa la metà del corpus di driver in commercio e sono frequentemente sfruttati negli attacchi "Bring Your Own Vulnerable Driver" (BYOVD). Inoltre, questi strumenti tipicamente emettono elenchi di scoperte "one-shot" e scartano i dati strutturali recuperati, impedendo l'analisi o la ri-valutazione cross-driver.

Metodologia
Gli autori propongono una pipeline deterministica e indipendente dall'architettura chiamata Windows IOCTL Census, che elabora un corpus di 27.087 driver Windows firmati attraverso tre fasi: Recover (Recupero), Enrich (Arricchimento) e Rank (Classificazione).

1. Recover (Passaggio Deterministico):

   • Architettura: Questa fase evita completamente l'esecuzione simbolica. Inveve, solleva i binari dei driver in una rappresentazione intermedia (IR) indipendente dall'architettura utilizzando il framework glaurung.
   • Recupero del Dispatch: Identifica l'handler IRP_MJ_DEVICE_CONTROL e decodifica i codici di controllo analizzando costanti di confronto e tabelle di salto (jump tables). Questo approccio recupera con successo le superfici di dispatch sia per architetture x64 che x86.
   • Analisi Strutturale: Per i driver x64, la pipeline costruisce grafi di chiamata inter-procedurali, esegue l'analisi di raggiungibilità dai processi di dispatch ed esegue un'analisi di taint leggera. La sorgente del taint è il puntatore all'input bufferizzato (Irp->AssociatedIrp.SystemBuffer), tracciandolo fino ai sink (dereferenziazioni o memorizzazioni) per identificare input controllati non sanitizzati.
   • Provenienza: Estrae metadati PE, informazioni di firma Authenticode e descrittori di sicurezza del dispositivo (SDDL) per segnalare driver con liste di controllo accessi (ACL) permissive.
   • Vincoli: L'analisi è limitata dalla dimensione del driver (saltando la disassemblazione completa per driver >4MB) e dall'architettura (gli x86 ricevono solo l'analisi della superficie senza deep taint/call graph a causa della mancanza di oracle di validazione indipendenti).

2. Enrich (Passaggio del Modello):

   • Targeting: Questa fase viene eseguita solo su un sottoinsieme ristretto e ad alta priorità: routine di dispatch in driver con descrittori di dispositivo permissivi che contengono almeno un sink di input-bufferizzato non sanitizzato.
   • Integrazione LLM: Un Large Language Model (LLM) viene istruito con un riepilogo compatto delle caratteristiche (descrittore del dispositivo, codici decodificati, dettagli del sink di taint e un estratto del disassembly) per generare un verdetto strutturato. Il verdetto include livelli di rischio, tipi di primitivi (ad esempio, out-of-bounds write) e razionale. Il modello è esplicitamente istruito a non vedere i byte decompilati grezzi per evitare allucinazioni, affidandosi invece ai fatti deterministici.

3. Rank (Interfaccia di Query):

   • Il sistema espone i dati attraverso viste relazionali. Le viste chiave includono una vista "hunt" che classifica gli handler raggiungibili dall'utente in base al numero di sink non sanitizzati, una vista "cross-driver" che raggruppa i codici di controllo condivisi tra diversi vendor, e una vista "oracle-agreement" che confronta i risultati del taint statico con i risultati dell'esecuzione simbolica ingeriti.

Contributi Chiave

• Un Database Pubblico e Interrogabile: Gli autori rilasciano un dataset contenente 27.087 binari, 3,1 milioni di codici di controllo decodificati, 8,18 milioni di funzioni e 15,9 milioni di archi di chiamata.
• Copertura Indipendente dall'Architettura: Utilizzando il lifting in IR anziché l'esecuzione simbolica, lo strumento recupera le superfici di dispatch per l'80% del corpus (21.708 driver), includendo la metà a 3 32 bit (x86) che gli scanner simbolici tipicamente abbandonano.
• Persistenza Strutturale: A differenza degli strumenti precedenti che scartano la struttura dopo il ritrovamento dei bug, questo censimento persiste il grafo di chiamata, i sink di taint e i codici decodificati, consentendo query come "quali driver condividono questo specifico codice di controllo?" o "quali handler raggiungono un sink di copia senza un controllo della lunghezza?".
• Validazione Ibrida: Il sistema integra l'analisi di taint statica con i risultati dell'esecuzione simbolica (tramite ioctlance) per cross-validare i risultati, dimostrando che i due metodi hanno blind spot complementari (ad esempio, il taint statico manca i codici METHOD_NEITHER, mentre l'esecuzione simbolica fatica con l'esplosione dei percorsi).

Risultati

• Copertura: Il passaggio deterministico ha recuperato una superficie di dispatch per 21.708 driver (80,1% del corpus). Il "deep lane" x64 ha prodotto 8,18 milioni di funzioni e 63.263 sink di taint di input-bufferizzato.
• Efficienza di Filtraggio: Il filtro deterministico (descrittore permissivo + sink non sanitizzato) ha ridotto i 27.087 driver a 330 handler candidati per l'arricchimento LLM.
• Performance del Modello: L'LLM ha classificato 135 dei 329 handler arricchiti come "critici" e 159 come "alti". Gli autori sottolineano che queste sono ipotesi di prioritizzazione, non bug confermati, senza alcun tasso di veri positivi riportato.
• Accordo tra Metodi: In un confronto con ioctlance su un campione di 1.000 driver, i due metodi concordavano su il 65% dei driver segnalati dal motore simbolico. Il disaccordo è stato attribuito principalmente all'incapacità del motore simbolico di raggiungere determinati handler (tetto di raggiungibilità) piuttosto che a errori di precisione.
• Backtesting: Un backtest contro i CVE noti e il catalogo LOLDrivers ha mostrato che la classificazione è efficace nel suo ambito (ad esempio, un handler vulnerabile noto in nvlddmkm.sys è stato classificato tra lo 0,14% superiore). Tuttavia, il sistema ha mancato vulnerabilità in driver di framework (WDF/KMDF) dove l'input viene recuperato tramite meccanismi diversi non coperti dalla sorgente di taint dell'input-bufferizzato.

Significato e Rivendicazioni
Il paper rivendica la sua importanza non come un rilevatore di vulnerabilità che prova l'esistenza di nuovi bug, ma come una mappa fondamentale della superficie dei codici di controllo dei driver Windows.

• Passaggio dal Rilevamento alla Navigazione: Gli autori sostengono che la comunità abbia bisogno di un record persistente e interrogabile della superficie di attacco per dare priorità alle scarse risorse di reverse engineering. Il censimento permette ai ricercatori di navigare nella "coda lunga" dei driver in commercio piuttosto che affidarsi alla fortuna o a target selezionati manualmente.
• Democratizzazione dell'Accesso: Rilasciando i dati strutturali (decodifica, grafi di chiamata, raggiungibilità) pur trattenendo il livello di targeting specifico (sink di taint e verdetti del modello) per prevenire l'uso duale (dual-use) malevolo, gli autori mirano ad abbassare la barriera all'ingresso per l'analisi della sicurezza dei driver.
• Complementarità: Il lavoro dimostra che la recuperazione deterministica e l'esecuzione simbolica sono complementari; il censimento fornisce il contesto strutturale che permette a questi metodi di controllarsi a vicenda e coprire i blind spot.
• Lavoro Futuro: Gli autori riconoscono i limiti, tra cui la mancanza di analisi di taint per x86 e arm64, l'esclusione dei percorsi METHOD_NEITHER e direct-I/O, e l'incapacità di gestire descrittori di dispositivo applicati a runtime. Inquadrano il censimento come un'infrastruttura viva che può essere estesa con nuovi analizzatori (ad esempio, per driver di framework o primitive di memoria fisica) senza dover ricostruire il nucleo centrale.