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

Résumé Technique : Le Recensement des IOCTL Windows

Énoncé du Problème
Le chemin de contrôle des périphériques dans Windows représente une surface d'attaque critique où des processus non privilégiés peuvent atteindre la mémoire du noyau via des codes de contrôle d'E/S (IOCTL). Les vulnérabilités dans ce chemin, telles que les longueurs de tampon non vérifiées, permettent l'élévation de privilèges. Bien que la communauté de la sécurité possède des scanners (par exemple, ScrewedDrivers, POPKORN, ioctlance) qui exécutent symboliquement les pilotes pour trouver des vulnérabilités spécifiques, et des listes curatées (par exemple, LOLDrivers) qui suivent les pilotes connus comme malveillants, il n'existe pas de carte systématique et persistante de la surface de dispatch des codes de contrôle sur l'ensemble de l'écosystème des pilotes. Les outils symboliques existants souffrent d'une explosion de chemins, de taux élevés de faux négatifs et de limitations architecturales ; notamment, ils échouent souvent sur les pilotes 32 bits (x86), qui constituent environ la moitié du corpus de pilotes distribués et sont fréquemment exploités dans les attaques de type « Bring Your Own Vulnerable Driver » (BYOVD). De plus, ces outils produisent généralement des listes de découvertes ponctuelles et rejettent les données structurelles récupérées, empêchant ainsi l'analyse ou la réévaluation croisée entre pilotes.

Méthodologie
Les auteurs proposent un pipeline déterministe et neutre vis-à-vis de l'architecture appelé le Windows IOCTL Census, qui traite un corpus de 27 087 pilotes Windows signés à travers trois étapes : Récupérer (Recover), Enrichir (Enrich) et Classer (Rank).

1. Récupérer (Passage Déterministe) :

   • Architecture : Cette étape évite totalement l'exécution symbolique. Au lieu de cela, elle lève les binaires des pilotes vers une représentation intermédiaire (IR) indépendante de l'architecture en utilisant le framework glaurung.
   • Récupération du Dispatch : Elle identifie le gestionnaire IRP_MJ_DEVICE_CONTROL et décode les codes de contrôle en analysant les constantes de comparaison et les tables de saut (jump tables). Cette approche permet de récupérer avec succès les surfaces de dispatch pour les architectures x64 et x86.
   • Analyse Structurelle : Pour les pilotes x64, le pipeline construit des graphes d'appels inter-procéduraux, effectue une analyse de reachabilité à partir des routines de dispatch, et exécute une analyse de propagation de données (taint analysis) légère. La source de la donnée (taint source) est le pointeur d'entrée tamponné (Irp->AssociatedIrp.SystemBuffer), suivi jusqu'aux puits (sinks) (déréférencements ou écritures) pour identifier les entrées contrôlées non assainies.
   • Provenance : Il extrait les métadonnées PE, les informations de signature Authenticode et les descripteurs de sécurité de périphérique (SDDL) pour signaler les pilotes ayant des listes de contrôle d'accès (ACL) permissives.
   • Contraintes : L'analyse est limitée par la taille du pilote (en sautant le désassemblage complet pour les pilotes > 4 Mo) et par l'architecture (le x86 reçoit une analyse de surface uniquement, sans analyse de taint profonde ou graphe d'appels, en raison de l'absence d'oracles de validation indépendants).

2. Enrichir (Passage Modèle) :

   • Ciblage : Cette étape ne s'exécute que sur un sous-ensemble étroit et prioritaire : les routines de dispatch dans les pilotes possédant des descripteurs de périphériques permissifs qui contiennent au moins un puits de données d'entrée tamponnées non assaini.
   • Intégration de l'LLM : Un grand modèle de langage (LLM) est sollicité avec un résumé compact des caractéristiques (descripteur de périphérique, codes décodés, détails du puits de taint, et un extrait de désassemblage) pour générer un verdict structuré. Le verdict inclut les niveaux de risque, les types de primitives (par exemple, écriture hors limites) et la justification. Le modèle est explicitement instruit de ne pas voir les octets décompilés bruts afin d'éviter les hallucinations, s'appuyant plutôt sur les faits déterministes.

3. Classer (Interface de Requête) :

   • Le système expose les données via des vues relationnelles. Les vues clés incluent une vue de « chasse » classant les gestionnaires accessibles par l'utilisateur selon le nombre de puits non assainis, une vue « inter-pilotes » regroupant les codes de contrôle partagés entre vendeurs, et une vue « accord de l'oracle » comparant les résultats de taint statique avec les résultats d'exécution symbolique ingérés.

Contributions Clés

• Une Base de Données Publique et Interrogeable : Les auteurs publient un ensemble de données contenant 27 087 binaires, 3,1 millions de codes de contrôle décodés, 8,18 millions de fonctions et 15,95 millions d'arêtes d'appel.
• Couverture Neutre vis-à-vis de l'Architecture : En utilisant le levage en IR plutôt que l'exécution symbolique, l'outil récupère les surfaces de dispatch pour 80 % du corpus (21 708 pilotes), incluant la moitié x86 en 32 bits que les scanners symboliques abandonnent généralement.
• Persistance Structurelle : Contrairement aux outils précédents qui rejettent la structure après avoir trouvé des bugs, ce recensement persiste le graphe d'appels, les puits de taint et les codes décodés, permettant des requêtes telles que « quels pilotes partagent ce code de contrôle spécifique ? » ou « quels gestionnaires atteignent un puits de copie sans vérification de longueur ? ».
• Validation Hybride : Le système intègre l'analyse de taint statique avec les résultats d'exécution symbolique (via ioctlance) pour valider de manière croisée les découvertes, démontrant que les deux méthodes ont des angles morts complémentaires (par exemple, le taint statique manque les codes METHOD_NEITHER, tandis que l'exécution symbolique peine face à l'explosion de chemins).

Résultats

• Couverture : Le passage déterministe a récupéré une surface de dispatch pour 21 708 pilotes (80,1 % du corpus). La voie profonde x64 a produit 8,18 millions de fonctions et 63 263 puits de taint d'entrée tamponnée.
• Efficacité du Filtrage : Les filtres déterministes (descripteur permissif + puits non assaini) ont réduit les 27 087 pilotes à 330 gestionnaires candidats pour l'enrichissement par LLM.
• Performance du Modèle : L'LLM a classé 135 des 329 gestionnaires enrichis comme « critiques » et 159 comme « élevés ». Les auteurs soulignent qu'il s'agit d'hypothèses de priorisation et non de bugs confirmés, sans taux de vrais positifs rapporté.
• Accord entre Méthodes : Dans une comparaison avec ioctlance sur un échantillon de 1 000 pilotes, les deux méthodes se sont accordées sur 65 % des pilotes signalés par le moteur symbolique. Le désaccord était largement attribué à l'incapacité du moteur symbolique à atteindre certains gestionnaires (plafond de reachabilité) plutôt qu'à des erreurs de précision.
• Backtesting : Un test rétrospectif contre les CVE connues et le catalogue LODrivers a montré que le classement est efficace dans son périmètre (par exemple, un gestionnaire connu comme vulnérable dans nvlddmkm.sys a été classé dans le top 0,14 %). Cependant, le système a manqué des vulnérabilités dans les pilotes de framework (WDF/KMDF) où l'entrée est récupérée via des mécanismes différents non couverts par la source de taint d'entrée tamponnée.

Signification et Revendications
Le papier revendique sa signification non pas comme un détecteur de vulnérabilités prouvant l'existence de nouveaux bugs, mais comme une carte fondamentale de la surface des codes de contrôle des pilotes Windows.

• Passage de la Détection à la Navigation : Les auteurs soutiennent que la communauté a besoin d'un enregistrement persistant et interrogeable de la surface d'attaque pour prioriser les ressources limitées de rétro-ingénierie. Le recensement permet aux chercheurs de naviguer dans la « longue traîne » des pilotes distribués plutôt que de compter sur la chance ou des cibles choisies à la main.
• Démocratisation de l'Accès : En publiant les données structurelles (décodage, graphes d'appels, reachabilité) tout en retenant le niveau de ciblage spécifique (puits de taint et verdicts de modèles) pour éviter le double usage malveillant, les auteurs visent à abaisser la barrière à l'entrée pour l'analyse de la sécurité des pilotes.
• Complémentarité : Le travail démontre que le recouvrement déterministe et l'exécution symbolique sont complémentaires ; le recensement fournit le contexte structurel qui permet à ces méthodes de se vérifier mutuellement et de couvrir les angles morts.
• Travaux Futurs : Les auteurs reconnaissent des limitations, notamment l'absence d'analyse de taint pour x86 et arm64, l'exclusion des chemins METHOD_NEITHER et d'E/S directe, ainsi que l'incapacité à gérer les descripteurs de périphériques appliqués au runtime. Ils présentent le recensement comme une infrastructure vivante pouvant être étendue avec de nouveaux analyseurs (par exemple, pour les pilotes de framework ou les primitives de mémoire physique) sans reconstruire le noyau.