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

Résumé Technique : Le Recensement des IOCTL de Linux

Énoncé du Problème
L'appel système ioctl sert d'interface principale pour le contrôle des périphériques sous Linux, permettant aux programmes de l'espace utilisateur d'envoyer des codes de commande numériques et des tampons d'arguments aux pilotes du noyau. Bien qu'essentielle pour la configuration du matériel et la gestion d'état, cette interface représente une surface d'attaque locale vaste, hétérogène et mal cataloguée. Les pilotes définissent des milliers de commandes uniques, qui analysent souvent les arguments dans le contexte du noyau sans validation uniforme. Un gestionnaire qui fait confiance à une longueur d'argument non validée peut conduire à des lectures ou écritures de mémoire hors limites (out-of-bounds).

Les approches actuelles pour analyser cette surface sont fragmentées :

• Scanneurs dynamiques (ex. syzkaller) : Efficaces pour trouver des bogues d'exécution et des conditions de concurrence, mais limités à l'espace de commande spécifique auquel ils sont explicitement chargés d'exercer. Ils signalent les bogues déclenchés, pas l'espace de commande inexploré.
• Curation manuelle : Des listes comme le catalogue LPE (élévation de privilèges locale) non privilégié et la documentation de modélisation des menaces existent, mais ce sont des textes en prose tenus à la main, et non des énumérations systématiques et interrogeables de l'espace de commande décodé.

Il manque un inventaire persistant, dérivé de la source, qui cartographie l'intégralité de la surface de commande statique, incluant les dispatchers, les commandes décodées, les gestionnaires et les barrières de permission.

Méthodologie : Extract-Gate-Rank (Extraire-Filtrer-Classer)
Les auteurs présentent un pipeline déterministe, Extract-Gate-Rank, qui lit le code source du noyau Linux pour matérialiser une base de données relationnelle de la surface ioctl. Le processus opère sur une compilation allmodconfig (x86_64) couvrant 878 modules à travers 169 sous-arbres.

1. Extract (Extraction) :

   • Utilise un graphe de connaissances dérivé de libclang à partir du code source du noyau pour identifier les dispatchers ioctl (fonctions liées à unlocked_ioctl, compat_ioctl, ou proc_ops.proc_ioctl).
   • Parcourt les fermetures d'appels (call closures) jusqu'aux corps des gestionnaires de commande par commande.
   • Décodage des codes de commande : Un résolveur étend les macros _IOC par rapport aux en-têtes UAPI pour décoder les codes de commande à 32 bits en quatre champs : direction, taille, octet magique et ordinal.
   • Identification des Sinks (Puits) et des Gates (Barrières) : Enregistre les sinks d'entrée contrôlée (ex. copy_from_user) dans une fenêtre de saut d'appel fixe, et les barrières de permission (vérifications de capacités, hooks LSM, vérifications f_mode).
   • Heuristique de Sanitarisation : Marque un sink comme "non sanitisé" si aucun contrôle de limites strict ne précède dans l'ordre source de la même fonction. Il s'agit d'un proxy structurel, et non d'une preuve de contrôle de flux.

2. Gate (Filtrage) :

   • Applique un filtre de joignabilité du modèle de menace comme colonne interrogeable.
   • Un module est marqué capability_ungated si son chemin ioctl manque d'une barrière de capacité de type init-namespace (ex. CAP_SYS_ADMIN).
   • Cela agit comme une borne supérieure de condition nécessaire sur la joignabilité non privilégiée, et non comme un classificateur de l'ouverture réelle des nœuds. Cela exclut les pilotes de staging et les chemins debugfs selon la documentation du noyau.

3. Rank (Classement) :

   • Génère des vues relationnelles sur le magasin, en priorisant les dispatchers sans barrière de capacité avec des sinks non sanitisés.
   • Inclut une vue multi-modules regroupant les codes de commande partagés (type, ordinal, accès) à travers différents pilotes.
   • Une couche d'enrichissement par LLM optionnelle est incluse pour le triage mais est maintenue hors du chemin critique et dans un niveau de accès restreint.

Résultats Clés
Le recensement couvre la compilation allmodconfig x86_64 (84 % des fichiers sources in-tree) et inclut une compilation arm64 secondaire pour validation.

• Échelle : L'analyse a récupéré 586 points d'entrée de dispatcher ioctl à travers 337 modules, décodant 1 289 codes de commande _IOC uniques.
• Sinks et Gates : Elle a identifié 3 583 sinks d'entrée contrôlée et 1 298 barrières de permission.
• Joignabilité : Le filtre de menace a exclu 50 modules derrière des barrières de capacité strictes, admettant 281 modules comme borne supérieure de la joignabilité non privilégiée.
• Couverture d'Architecture : Une seconde compilation pour arm64 n'a ajouté qu'un seul module unique (Apple adp_drv) et aucun nouveau code de commande, indiquant que x86_64 couvre 99,7 % des modules porteurs d'ioctl.
• Partage de Commande : Les motifs de commande partagés (ex. commandes WDIOC_* de watchdog) réapparaissent dans plusieurs pilotes, suggérant qu'une vulnérabilité dans un motif partagé pourrait affecter de nombreux modules simultanément.
• Concentration de Capacité : Les barrières de permission sont dominées par CAP_SYS_ADMIN (512 occurrences), une capacité que le modèle de menace du noyau traite explicitement comme "hors modèle", réduisant davantage la surface d'attaque en scope.

Validation par Backtest
Les auteurs ont validé le recensement par rapport à 22 CVE ioctl récentes in-tree :

• Couverture : Tous les 22 CVE se trouvaient dans les sous-arbres couverts, éliminant les lacunes de couverture comme source d'erreur.
• Récupération : Le passage de récupération de dispatcher a trouvé le gestionnaire vulnérable pour 7 des 22 CVE.
• Manqués : Les 15 manqués sont entièrement attribuables aux limitations du modèle d'enregistrement :
  • 8 cas impliquaient des cœurs DRM/V4L2 utilisant un dispatch par table d'opérations (drm_ioctl_desc, vl2_ioctl_ops) où le cœur copie les arguments avant de les passer aux gestionnaires par commande.
  • 3 cas impliquaient des disciplines de ligne tty.
  • 4 cas étaient des fonctions atteintes uniquement en tant qu'appelées sous le dispatcher, et non le dispatcher lui-même.
• Précision du Filtre : Le filtre a correctement admis les 7 CVE trouvés. Deux étaient des "faux admis" concernant les restrictions de DAC de nœud (ex. pci_endpoint_test), ce que la méthode prédit correctement comme une limitation puisqu'elle n'analyse pas les permissions de nœud de périphérique, seulement les barrières de capacité.

Signification et Revendications
L'article positionne le Recensement des IOCTL de Linux comme une contribution de mesure et de jeu de données plutôt que comme un outil de recherche de bogues. Sa signification primaire réside dans :

1. Persistance et Interrogabilité : Il transforme la surface ioctl d'une liste transitoire de bogues en un magasin relationnel persistant et interrogeable. Cela permet aux auditeurs de poser des questions structurelles (ex. "Quels modules partagent ce code de commande ?") que les listes de bogues ne peuvent répondre.
2. Intégration du Modèle de Menace : Il encode directement dans le schéma de données les frontières de sécurité documentées du noyau, transformant la prose en filtres interrogeables.
3. Complémentarité : Il complète le fuzzing dynamique en énumérant l'intégralité de l'espace de commande statique, y compris les commandes qui pourraient manquer de harnesses ou de descriptions, guidant ainsi les outils dynamiques vers des zones inexplorées.
4. Schéma Cross-OS : Le jeu de données partage un schéma avec le recensement Windows compagnon, permettant des requêtes inter-plateformes.

Limitations
Les auteurs énoncent explicitement plusieurs limites :

• Joignabilité : Le compte "accessible par l'utilisateur" est une borne supérieure basée sur les barrières de capacité, et non une preuve de l'ouverture des nœuds (DAC).
• Sanitarisation : Le compte "non sanitisé" est un proxy heuristique basé sur l'ordre de la source, et non une preuve formelle de sécurité.
• Couverture : Elle est limitée à ce qu'une compilation allmodconfig compile ; d'autres architectures et pilotes qui ne peuvent être activés conjointement sont exclus.
• Modèle d'Enregistrement : Le modèle actuel manque les gestionnaires enregistrés via des tables d'opérations (DRM, V4L2, ALSA), les disciplines de ligne tty, et les fonctions auxiliaires situées sous le dispatcher.

Le jeu de données est publié en deux niveaux : un niveau structurel public (modules, dispatchers, codes, barrières) sous une licence ouverte, et un niveau de ciblage restreint (emplacements spécifiques des sinks, verdicts d'enrichissement et surface non privilégiée classée) pour empêcher l'exploitation à double usage tout en soutenant la recherche autorisée.