The Linux IOCTL Census: A Source-Derived Database of the Linux Kernel Control-Code Surface

Sintesi Tecnica: Il Censimento degli IOCTL di Linux

Problematica
La chiamata di sistema ioctl funge da interfaccia primaria per il controllo dei dispositivi in Linux, permettendo ai programmi in userspace di inviare codici di comando numerici e buffer di argomenti ai driver del kernel. Sebbene essenziale per la configurazione dell'hardware e la gestione dello stato, questa interfaccia rappresenta una superficie di attacco locale vasta, eterogenea e scarsamente catalogata. I driver definiscono migliaia di comandi unici, spesso analizzando gli argomenti in contesto kernel senza una validazione uniforme. Un gestore che si affida a una lunghezza di argomento non validata può portare a letture o scritture di memoria fuori dai limiti (out-of-bounds).

Gli approcci attuali per l'analisi di questa superficie sono frammentati:

• Scanner Dinamici (es. syzkaller): Efficaci nel trovare bug di runtime e condizioni di race, ma limitati allo spazio dei comandi specifico che gli viene esplicitamente indicato di esercitare. Riportano i bug che innescano, non lo spazio dei comandi inesplorato.
• Curatela Manuale: Liste come il catalogo LPE unprivileged-reach e la documentazione di threat-modeling esistono come prosa mantenuta manualmente, non come enumerazioni sistematiche e interrogabili dello spazio dei comandi decodificato.

Manca un inventario persistente, derivato dal codice sorgente, che mappi l'intero spazio statico dei comandi, inclusi dispatcher, comandi decodificati, gestori e gate di permessi.

Metodologia: Extract-Gate-Rank
Gli autori presentano una pipeline deterministica, Extract-Gate-Rank, che legge il codice sorgente del kernel Linux per materializzare un database relazionale della superficie ioctl. Il processo opera su una build allmodconfig (x86_64) che copre 878 moduli in 169 sottotree.

1. Extract (Estrazione):

   • Utilizza un grafo di conoscenza derivato da libclang dal codice sorgente del kernel per identificare i dispatcher ioctl (funzioni legate a unlocked_ioctl, compat_ioctl o proc_ops.proc_ioctl).
   • Percorre le chiusure di chiamata (call closures) fino ai corpi dei gestori per singolo comando.
   • Decodifica i Codici di Comando: Un risolutore espande le macro _IOC contro gli header UAPI per decodificare i codici di comando a 32 bit in quattro campi: direzione, dimensione, byte magic e ordinale.
   • Identifica Sink e Gate: Registra i sink di input controllato (es. copy_from_user) entro una finestra di salto di chiamata (call-hop window) fissa e i gate di permesso (controlli di capability, hook LSM, controlli f_mode).
   • Euristica di Sanitizzazione: Segna un sink come "non sanitizzato" se non esiste un precedente controllo dei limiti (bounds check) nel medesimo ordine sorgente della funzione. Questa è una proxy strutturale, non una prova di controllo del flusso.

2. Gate (Filtro):

   • Applica un filtro di raggiungibilità del modello di minaccia come colonna interrogabile.
   • Un modulo è marcato capability_ungated se il suo percorso ioctl manca di un gate di capacità (capability gate) di tipo init-namespace (es. CAP_SYS_ADMIN).
   • Questo funge da limite superiore di condizione necessaria sulla raggiungibilità da parte di utenti non privilegiati, non è un classificatore della reale apertura dei nodi. Esclude i driver di staging e i percorsi debugfs secondo la documentazione del kernel.

3. Rank (Classificazione):

   • Genera viste relazionali sul deposito, dando priorità ai dispatcher capability-ungated con sink non sanitizzati.
   • Include una vista cross-modulo che raggruppa i codici di comando condivisi (tipo, ordinale, accesso) tra diversi driver.
   • Un livello opzionale di arricchimento tramite LLM è incluso per il triage ma è mantenuto fuori dal percorso critico e in un tier trattenuto.

Risultati Chiave
Il censimento copre la build allmodconfig x86_64 (84% dei file sorgente in-tree) e include una build secondaria arm64 per validazione.

• Scala: L'analisi ha recuperato 586 punti di ingresso dispatcher ioctl attraverso 337 moduli, decodificando 1.289 codici di comando _IOC unici.
• Sink e Gate: Ha identificato 3.583 sink di input controllato e 1.298 gate di permesso.
• Raggiungibilità: Il filtro del modello di minaccia ha escluso 50 moduli dietro duri gate di capacità, ammettendo 281 moduli come limite superiore della raggiungibilità non privilegiata.
• Copertura Architetturale: Una seconda build per arm64 ha aggiunto solo un modulo unico (Apple adp_drv) e nessun nuovo codice di comando, indicando che x86_64 copre il 99,7% dei moduli che contengono ioctl.
• Condivisione dei Comandi: I pattern di comando condivisi (es. comandi watchdog WDIOC_*) ricorrono in più driver, suggerendo che una vulnerabilità in un pattern condiviso potrebbe influenzare molti moduli simultaneamente.
• Concentrazione di Capacità: I gate di permesso sono dominati da CAP_SYS_ADMIN (512 occorrenze), una capacità che il modello di minaccia del kernel tratta esplicitamente come "fuori dal modello", restringendo ulteriormente la superficie di attacco effettivamente in ambito.

Validazione Backtest
Gli autori hanno validato il censimento contro 22 recenti CVE ioctl in-tree:

• Copertura: Tutti i 22 CVE rientravano nei sottotree coperti, eliminando i gap di copertura come fonte di errore.
• Recupero: Il passaggio di recupero dei dispatcher ha trovato il gestore vulnerabile per 7 dei 22 CVE.
• Errori (Misses): I 15 casi mancanti sono interamente attribuibili alle limitazioni del modello di registrazione:
  • 8 casi coinvolgevano i core DRM/V4L2 che utilizzano la dispersione tramite tabelle di operazioni (drm_ioctl_desc, vl2_ioctl_ops), dove il core copia gli argomenti prima di passarli ai gestori per singolo comando.
  • 3 casi coinvolgevano le discipline di linea tty.
  • 4 casi riguardavano funzioni raggiunte solo come chiamanti sotto il dispatcher, non come il dispatcher stesso.
• Accuratezza del Filtro: Il filtro ha correttamente ammesso tutti i 7 CVE trovati. Due erano "falsi ammessi" riguardo alle restrizioni di nodo-DAC (Device Access Control) (es. pci_endpoint_test), che il metodo prevede correttamente come una limitazione poiché non analizza i permessi dei nodi dispositivo, solo i gate di capacità.

Significatività e Rivendicazioni
Il paper posiziona il Linux IOCTL Census come un contributo di misurazione e dataset piuttosto che come uno strumento di ricerca di bug. La sua principale significatività risiede in:

1. Persistenza e Interrogabilità: Trasforma la superficie ioctl da una lista transitoria di bug in un deposito relazionale persistente e interrogabile. Ciò permette agli auditor di porre domande strutturali (es. "Quali moduli condividono questo codice di comando?") che le liste di bug non possono rispondere.
2. Integrazione del Modello di Minaccia: Codifica direttamente nello schema dei dati il modello di minaccia del kernel, trasformando la prosa dei confini di sicurezza in filtri interrogabili.
3. Complementarità: Integra il fuzzing dinamico enumerando l'intero spazio statico dei comandi, inclusi i comandi che potrebbero mancare di harness o descrizioni, guidando così gli strumenti dinamici verso aree inesplorate.
4. Schema Cross-OS: Il dataset condivide uno schema con il compagno Windows IOCTL Census, consentendo query cross-platform.

Limitazioni
Gli autori dichiarano esplicitamente diversi limiti:

• Raggiungibilità: Il conteggio "raggiungibile dall'utente" è un limite superiore basato sui gate di capacità, non una prova della raggiungibilità del nodo (DAC).
• Sanitizzazione: Il conteggio "non sanitizzato" è una proxy euristica basata sull'ordine sorgente, non una prova formale di sicurezza.
• Copertura: È limitata a ciò che una build allmodconfig compila; altre architetture e driver che non possono essere abilitati contemporaneamente sono esclusi.
• Modello di Registrazione: Il modello attuale perde i gestori registrati tramite tabelle di operazioni (DRM, V4L2, ALSA), le discipline di linea tty e le funzioni helper al di sotto del dispatcher.

Il dataset è rilasciato in due tier: un tier strutturale pubblico (moduli, dispatcher, codici, gate) sotto una licenza aperta, e un tier di targeting trattenuto (posizioni specifiche dei sink, verdetti di arricchimento e superficie non privilegiata classificata) per prevenire l'uso duale malevolo pur supportando la ricerca autorizzata.