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

Resumen Técnico: El Censo de IOCTL de Windows

Declaración del Problema
La ruta de control de dispositivos en Windows representa una superficie de ataque crítica donde los procesos sin privilegios pueden alcanzar la memoria del kernel mediante códigos de control de E/S (IOCTL). Las vulnerabilidades en esta ruta, como las longitudes de búfer no verificadas, permiten la escalada de privilegios. Si bien la comunidad de seguridad posee escáneres (por ejemplo, ScrewedDrivers, POPKORN, ioctlance) que ejecutan simbólicamente los controladores para encontrar vulnerabilidades específicas, y listas curadas (por ejemplo, LOLDrivers) que rastrean controladores conocidos como maliciosos, no existe un mapa sistemático y persistente de la superficie de despacho de códigos de control en todo el ecosistema de controladores. Las herramientas simbólicas existentes sufren de explosión de rutas, altas tasas de falsos negativos y limitaciones arquitectónicas; notablemente, suelen fallar en controladores de 32 bits (x86), que constituyen aproximadamente la mitad del corpus de controladores distribuidos y son frecuentemente explotados en ataques de tipo "Trae Tu Propio Controlador Vulnerable" (BYOVD). Además, estas herramientas suelen emitir listas de hallazgos de un solo uso y descartan los datos estructurales recuperados, lo que impide el análisis o la reevaluación entre controladores.

Metodología
Los autores proponen un flujo de trabajo determinista y neutral a la arquitectura llamado Censo de IOCTL de Windows, que procesa un corpus de 27.087 controladores firmados de Windows a través de tres etapas: Recuperar, Enriquecer y Clasificar.

1. Recuperar (Pasada Determinista):

   • Arquitectura: Esta etapa evita la ejecución simbólica por completo. En su lugar, eleva los binarios de los controladores a una representación intermedia (IR) neutral a la arquitectura utilizando el marco glaurung.
   • Recuperación de Despacho: Identifica el manejador IRP_MJ_DEVICE_CONTROL y decodifica los códigos de control analizando constantes de comparación y tablas de saltos. Este enfoque logra recuperar superficies de despacho tanto para arquitecturas x64 como x86.
   • Análisis Estructural: Para controladores x64, el flujo de trabajo construye grafos de llamadas interprocedimentales, realiza un análisis de alcanzabilidad desde las rutinas de despacho y ejecuta un análisis de manchas (taint analysis) ligero. La fuente de la mancha es el puntero de entrada en búfer (Irp->AssociatedIrp.SystemBuffer), rastreándolo hasta los sumideros (sinks) (desreferencias o almacenamientos) para identificar entradas controladas no saneadas.
   • Procedencia: Extrae metadatos PE, información de firma Authenticode y descriptores de seguridad de dispositivos (SDDL) para señalar controladores con listas de control de acceso (ACL) permisivas.
   • Restricciones: El análisis está limitado por el tamaño del controlador (omitiendo la desensambladura completa para controladores >4MB) y la arquitectura (x86 recibe un análisis solo de superficie sin análisis profundo de manchas/grafos de llamadas debido a la falta de oráculos de validación independientes).

2. Enriquecer (Pasada de Modelo):

   • Objetivo: Esta etapa se ejecuta solo en un subconjunto estrecho y de alta prioridad: rutinas de despacho en controladores con descriptores de dispositivo permisivos que contienen al menos un sumidero de entrada en búfer no saneado.
   • Integración de LLM: Un Modelo de Lenguaje de Gran Escala (LLM) es instruido con un resumen compacto de características (descriptor de dispositivo, códigos decodificados, detalles del sumidero de mancha y un extracto de desensamblado) para generar un veredicto estructurado. El veredicto incluye niveles de riesgo, tipos de primitivas (por ejemplo, escritura fuera de límites) y la justificación. Se le instruye explícitamente al modelo que no vea bytes descompilados en bruto para evitar alucinaciones, basándose en los hechos deterministas.

3. Clasificar (Interfaz de Consulta):

   • El sistema expone los datos a través de vistas relacionales. Las vistas clave incluyen una vista de "búsqueda" (hunt) que clasifica los manejadores alcanzables por el usuario según el recuento de sumideros no saneados, una vista "entre controladores" que agrupa códigos de control compartidos entre proveedores, y una vista de "acuerdo de oráculo" que compara los resultados de mancha estática contra los resultados de ejecución simbólica ingeridos.

Contribuciones Clave

• Una Base de Datos Pública y Consultable: Los autores lanzan un conjunto de datos que contiene 27.087 binarios, 3,1 millones de códigos de control decodificados, 8,18 millones de funciones y 15,95 millones de aristas de llamadas.
• Cobertura Neutral a la Arquitectura: Al utilizar la elevación a IR en lugar de la ejecución simbólica, la herramienta recupera superficies de despacho para el 80% del corpus (21.708 controladores), incluyendo la mitad de 32 bits (x86) que los escáneres simbólicos típicamente abortan.
• Persistencia Estructural: A diferencia de las herramientas anteriores que descartan la estructura tras encontrar errores, este censo persiste el grafo de llamadas, los sumideros de mancha y los códigos decodificados, permitiendo consultas como "¿qué controladores comparten este código de control específico?" o "¿qué manejadores alcanzan un sumidero de copia sin una verificación de longitud?".
• Validación Híbrida: El sistema integra el análisis de mancha estática con los resultados de la ejecución simbólica (vía ioctlance) para validar de forma cruzada los hallazgos, demostrando que ambos métodos tienen puntos ciegos complementarios (por ejemplo, el análisis de mancha estática omite códigos METHOD_NEITHER, mientras que la ejecución simbólica lucha contra la explosión de rutas).

Resultos

• Cobertura: La pasada determinista recuperó una superficie de despacho para 21.708 controladores (80,1% del corpus). El carril profundo de x64 produjo 8,18 millones de funciones y 63.263 sumideros de mancha de entrada en búfer.
• Eficiencia de Filtrado: El filtro determinista (descriptor permisivo + sumidero no saneado) redujo los 27.087 controladores a 330 manejadores candidatos para el enriquecimiento por LLM.
• Rendimiento del Modelo: El LLM calificó 135 de los 329 manejadores enriquecidos como "críticos" y 159 como "altos". Los autores enfatizan que estas son hipótesis de priorización, no errores confirmados, sin una tasa de verdaderos positivos reportada.
• Acuerdo entre Métodos: En una comparación con ioctlance sobre una muestra de 1.000 controladores, los dos métodos coincidieron en el 65% de los controladores marcados por el motor simbólico. El desacuerdo se atribuyó principalmente a la incapacidad del motor simbólico para alcanzar ciertos manejadores (techo de alcanzabilidad) más que a errores de precisión.
• Prueba Retrospectiva (Backtesting): Una prueba retrospectiva contra CVEs conocidos y el catálogo LOLDrivers mostró que la clasificación es efectiva dentro de su alcance (por ejemplo, un manejador vulnerable conocido en nvlddmkm.sys se clasificó en el top 0,14%). Sin embargo, el sistema omitió vulnerabilidades en controladores de marco (WDF/KMDF) donde la entrada se recupera mediante mecanismos diferentes no cubiertos por la fuente de mancha de entrada en búfer.

Significancia y Reivindicaciones
El artículo reclama significancia no como un detector de vulnerabilidades que prueba la existencia de nuevos errores, sino como un mapa fundacional de la superficie de códigos de control de los controladores de Windows.

• Cambio de la Detección a la Navegación: Los autores argumentan que la comunidad necesita un registro persistente y consultable de la superficie de ataque para priorizar los escasos recursos de ingeniería inversa. El censo permite a los investigadores navegar por la "larga cola" de los controladores distribuidos en lugar de depender de la suerte o de objetivos seleccionados a mano.
• Democratización del Acceso: Al liberar los datos estructurales (decodificación, grafos de llamadas, alcanzabilidad) mientras se retiene el nivel de segmentación específico (sumideros de mancha y veredictos del modelo) para evitar la explotación de doble uso, los autores pretenden reducir la barrera de entrada para el análisis de la seguridad de los controladores.
• Complementariedad: El trabajo demuestra que la recuperación determinista y la ejecución simbólica son complementarias; el censo proporciona el contexto estructural que permite a estos métodos verificarse entre sí y cubrir puntos ciegos.
• Trabajo Futuro: Los autores reconocen limitaciones, incluyendo la falta de análisis de mancha para x86 y arm64, la exclusión de rutas METHOD_NEITHER y de E/S directa, y la incapacidad de manejar descriptores de dispositivo aplicados en tiempo de ejecución. Plantean el censo como una infraestructura viva que puede extenderse con nuevos analizadores (por ejemplo, para controladores de marco o primitivas de memoria física) sin reconstruir el núcleo.