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

Resumen Técnico: El Censo de IOCTL de Linux

Planteamiento del Problema
La llamada al sistema ioctl sirve como la interfaz principal de control de dispositivos de Linux, permitiendo que los programas de espacio de usuario envíen códigos de comando numéricos y búferes de argumentos al kernel. Aunque es esencial para la configuración de hardware y la gestión de estados, esta interfaz representa una superficie de ataque local vasta, heterogénea y mal catalogada. Los controladores definen miles de comandos únicos, que a menudo procesan argumentos en el contexto del kernel sin una validación uniforme. Un manejador que confía en una longitud de argumento no validada puede provocar lecturas o escritas de memoria fuera de límites (out-of-bounds).

Los enfoques actuales para analizar esta superficie están fragmentados:

• Escáneres Dinámicos (p. ej., syzkaller): Efectivos para encontrar errores de tiempo de ejecución y condiciones de carrera, pero limitados al espacio de comandos específico para el cual se les indica explícitamente que operen. Reportan errores disparados, no el espacio de comandos no explorado.
• Curación Manual: Existen listas como el catálogo de LPE de alcance no privilegiado y documentación de modelos de amenazas, pero son prosa mantenida manualmente, no enumeraciones sistemáticas y consultables del espacio de comandos decodificado.

Existe una falta de un inventario persistente, derivado de la fuente, que mapee todo el catálogo estático de comandos, incluyendo despachadores, comandos decodificados, manejadores y puertas de permisos.

Metodología: Extract-Gate-Rank (Extraer-Filtrar-Clasificar)
Los autores presentan un pipeline determinista, Extract-Gate-Rank, que lee el código fuente del kernel de Linux para materializar una base de datos relacional de la superficie de ioctl. El proceso opera sobre una compilación allmodconfig (x86_64) que cubre 878 módulos en 169 subárboles.

1. Extract (Extraer):

   • Utiliza un grafo de conocimiento derivado de libclang del código fuente del kernel para identificar los despachadores de ioctl (funciones vinculadas a unlocked_ioctl, compat_ioctl o proc_ops.proc_ioctl).
   • Recorre los cierres de llamadas (call closures) hacia los cuerpos de los manejadores por comando.
   • Decodifica Códigos de Comando: Un resolvedor expande las macros _IOC contra los encabezados UAPI para decodificar los códigos de comando de 32 bits en cuatro campos: dirección, tamaño, byte mágico y ordinal.
   • Identifica Sinks (Sumideros) y Gates (Puertas): Registra sumideros de entrada controlada (p. ej., copy_from_user) dentro de una ventana de saltos de llamada fija y puertas de permisos (verificaciones de capacidad, ganchos de LSM, verificaciones de f_mode).
   • Heurística de Sanitización: Marca un sumidero como "no sanitizado" si no existe una verificación previa de límites estrictos en el mismo orden de fuente de la función. Esta es una aproximación estructural, no una prueba de flujo de control.

2. Gate (Filtrar):

   • Aplica un filtro de alcanzabilidad de modelo de amenazas como una columna consultable.
   • Un módulo se marca como capability_ungated si su ruta de ioctl carece de una puerta de capacidad de init-namespace estricta (p. ej., CAP_SYS_ADMIN).
   • Esto actúa como un límite superior de condición necesaria para el alcance no privilegiado, no como un clasificador de la apertura de nodos. Excluye controladores de staging y rutas de debugfs según la documentación del kernel.

3. Rank (Clasificar):

   • Genera vistas relacionales sobre el almacén, priorizando los despachadores sin capacidad (capability-ungated) con sumideros no sanitizados.
   • Incluye una vista trans-módulo que agrupa códigos de comando compartidos (tipo, ordinal, acceso) a través de diferentes controladores.
   • Se incluye una capa de enriquecimiento opcional mediante LLM para el triaje, pero se mantiene fuera de la ruta crítica y en un nivel retenido.

Resultados Clave
El censo cubre la compilación allmodconfig de x86_64 (84% de los archivos de fuente in-tree) e incluye una segunda compilación para arm64 para validación.

• Escala: El análisis recuperó 586 puntos de entrada de despacho de ioctl a través de 337 módulos, decodificando 1,289 códigos de comando _IOC únicos.
• Sinks y Gates: Identificó 3,583 sumideros de entrada controlada y 1,298 puertas de permisos.
• Alcanzabilidad: El filtro de modelo de amenazas excluyó 50 módulos detrás de puertas de capacidad estrictas, admitiendo 281 módulos como el límite superior de alcance no privilegiado.
• Cobertura de Arquitectura: Una segunda compilación para arm64 añadió solo un módulo único (Apple adp_drv) y ningún código de comando nuevo, lo que indica que x86_64 cubre el 99.7% de los módulos que portan ioctl.
• Compartición de Comandos: Los patrones de comandos compartidos (p. ej., comandos WDIOC_* de watchdog) recurren en múltiples controladores, sugiriendo que una vulnerabilidad en un patrón compartido podría afectar a muchos módulos simultáneamente.
• Concentración de Capacidades: Las puertas de permisos están dominadas por CAP_SYS_ADMIN (512 ocurrencias), una capacidad que el modelo de amenazas del kernel trata explícitamente como "fuera del modelo", estrechando aún más la superficie de ataque en el alcance.

Validación de Backtest
Los autores validaron el censo contra 22 CVE recientes de io-tree:

• Cobertura: Todos los 22 CVEs se encontraban dentro de los subárboles cubiertos, eliminando las brechas de cobertura como fuente de error.
• Recuperación: El paso de recuperación de despachador encontró el manejador vulnerable para 7 de los 22 CVEs.
• Omisiones: Las 15 omisiones se atribuyeron enteramente a limitaciones del modelo de registro:
  • 8 casos involucraron núcleos DRM/V4L2 que usan despacho de tablas de operaciones (drm_ioctl_desc, v4l2_ioctl_ops) donde el núcleo copia los argumentos antes de pasarlos a los manejadores por comando.
  • 3 casos involucraron disciplinas de línea de tty.
  • 4 casos fueron funciones alcanzadas solo como llamadas a funciones debajo del despachador, no el despachador mismo.
• Precisión del Filtro: El filtro admitió correctamente los 7 CVEs encontrados. Dos fueron "falsos admitidos" respecto a las restricciones de nodo-DAC (Control de Acceso de Dispositivo) (p. ej., pci_endpoint_test), lo cual el método predice correctamente como una limitación, ya que no analiza los permisos de los nodos de dispositivo, solo las puertas de capacidad.

Significancia y Reivindicaciones
El artículo posiciona el Censo de IOCTL de Linux como una contribución de medición y conjunto de datos en lugar de una herramienta de búsqueda de errores. Su principal significancia radica en:

1. Persistencia y Consultabilidad: Transforma la superficie de ioctl de una lista transitoria de errores en un almacén relacional persistente y consultable. Esto permite a los auditores hacer preguntas estructurales (p. ej., "¿Qué módulos comparten este código de comando?") que las listas de errores no pueden responder.
2. Integración del Modelo de Amenazas: Codifica el modelo de amenazas documentado del kernel directamente en el esquema de datos, convirtiendo la prosa de los límites de seguridad en filtros consultables.
3. Complementariedad: Complementa el fuzzing dinámico al enumerar toda la superficie estática de comandos, incluyendo comandos que pueden carecer de harnesses o descripciones, guiando así a las herramientas dinámicas hacia áreas no exploradas.
4. Esquema Cross-OS: El conjunto de datos comparte un esquema con el censo de IOCTL de Windows complementario, permitiendo consultas multiplataforma.

Limitaciones
Los autores declaran explícitamente varios límites:

• Alcanzabilidad: El recuento de "usuario-alcanzable" es un límite superior basado en puertas de capacidad, no una prueba de la apertura de nodos (DAC).
• Sanitización: El recuento de "no sanitizado" es un proxy heurístico basado en el orden de la fuente, no una prueba formal de seguridad.
• Cobertura: Está limitado a lo que una compilación allmodconfig compila; otras arquitecturas y controladores que no pueden habilitarse simultáneamente quedan excluidos.
• Modelo de Registro: El modelo actual omite manejadores registrados mediante tablas de operaciones (DRM, V4L2, ALSA), disciplinas de línea de tty y funciones auxiliares debajo del despachador.

El conjunto de datos se libera en dos niveles: un nivel estructural público (módulos, despachadores, códigos, puertas) bajo una licencia abierta, y un nivel de segmentación retenido (ubicaciones específicas de sumideros, veredictos de enriquecimiento y superficie no privilegiada clasificada) para evitar la explotación de doble uso mientras se apoya la investigación autorizada.