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

Resumo Técnico: O Censo de IOCTL do Windows

Definição do Problema
O caminho de controle de dispositivos no Windows representa uma superfície de ataque crítica, onde processos sem privilégios podem alcançar a memória do kernel por meio de códigos de controle de E/S (IOCTL). Vulnerabilidades nesse caminho, como comprimentos de buffer não verificados, permitem a escalada de privilégios. Embora a comunidade de segurança possua scanners (ex: ScrewedDrivers, POPKORN, ioctlance) que executam simbolicamente drivers para encontrar vulnerabilidades específicas, e listas curadas (ex: LOLDrivers) que rastreiam drivers conhecidos como maliciosos, não existe um mapa sistemático e persistente da superfície de despacho de códigos de controle em todo o ecossistema de drivers. As ferramentas simbólicas existentes sofrem de explosão de caminhos, altas taxas de falsos negativos e limitações arquiteturais; notadamente, elas frequentemente falham em drivers de 32 bits (x86), que constituem aproximadamente metade do corpus de drivers distribuídos e são frequentemente explorados em ataques de "Bring Your Own Vulnerable Driver" (BYOVD). Além além disso, essas ferramentas tipicamente emitem listas de descobertas de uso único e descartam os dados estruturais recuperados, impedindo a análise ou reavaliação entre diferentes drivers.

Metodologia
Os autores propõem um pipeline determinístico e neutro de arquitetura chamado Windows IOCTL Census, que processa um corpus de 27.087 drivers assinados do Windows através de três estágios: Recuperar (Recover), Enriquecer (Enrich) e Classificar (Rank).

1. Recuperar (Passo Determinístico):

   • Arquitetura: Este estágio evita totalmente a execução simbólica. Em vez disso, ele eleva os binários dos drivers para uma representação intermediária (IR) neutra de arquitetura usando o framework glaurung.
   • Recuperação de Despacho: Identifica o manipulador IRP_MJ_DEVICE_CONTROL e decodifica os códigos de controle analisando constantes de comparação e tabelas de salto (jump tables). Esta abordagem recupera com sucesso as superfícies de despacho para as arquiteturas x64 e x86.
   • Análise Estrutural: Para drivers x64, o pipeline constrói grafos de chamadas interprocedurais, realiza análise de alcançabilidade a partir das rotinas de despacho e executa uma análise de contaminação (taint analysis) leve. A fonte de contaminação é o ponteiro de entrada bufferizada (Irp->AssociatedIrp.SystemBuffer), rastreando-o até os sumidouros (sinks) (desreferenciações ou armazenamentos) para identificar entradas controladas não sanitizadas.
   • Proveniência: Extrai metadados PE, informações de assinatura Authenticode e descritores de segurança de dispositivo (SDDL) para sinalizar drivers com listas de controle de acesso (ACLs) permissivas.
   • Restrições: A análise é limitada pelo tamanho do driver (pulando a desmontagem completa para drivers >4MB) e pela arquitetura (x86 recebe apenas análise de superfície sem análise profunda de contaminação/grafo de chamadas devido à falta de oráculos de validação independentes).

2. Enriquecer (Passo de Modelo):

   • Direcionamento: Este estágio roda apenas em um subconjunto estreito e de alta prioridade: rotinas de despacho em drivers com descritores de dispositivo permissivos que contenham pelo menos um sumidouro de entrada-bufferizada não sanitizado.
   • Integração com LLM: Um Modelo de Linguagem de Grande Escala (LLM) é instruído com um resumo compacto de características (descritor de dispositivo, códigos decodificados, detalhes do sumidouro de contaminação e um trecho de desmontagem) para gerar um veredito estruturado. O veredito inclui níveis de risco, tipos de primitivas (ex: escrita fora dos limites) e justificativa. O modelo é explicitamente instruído a não ver bytes descompilados brutos para evitar alucinações, baseando-se em fatos determinísticos.

3. Classificar (Interface de Consulta):

   • O sistema expõe os dados através de visualizações relacionais. As visualizações principais incluem uma visão de "caça" (hunt) que classifica os manipuladores alcançáveis pelo usuário pelo número de sumidouros de contaminação não sanitizados, uma visão "entre drivers" (cross-driver) que agrupa códigos de controle compartilhados entre fornecedores, e uma visão de "acordo de oráculo" (oracle-agreement) que compara os resultados de contaminação estática contra os resultados de execução simbólica ingeridos.

Principais Contribuições

• Um Banco de Dados Público e Consultável: Os autores liberam um conjunto de dados contendo 27.087 binários, 3,1 milhões de códigos de controle decodificados, 8,18 milhões de funções e 15,95 milhões de arestas de chamada.
• Cobertura Neutra de Arquitetura: Ao usar a elevação para IR em vez de execução simbólica, a ferramenta recupera superfícies de despacho para 80% do corpus (21.708 drivers), incluindo a metade de 32 bits (x86) que os scanners simbólicos tipicamente abortam.
• Persistência Estrutural: Diferente de ferramentas anteriores que descartam a estrutura após encontrar bugs, este censo persiste o grafo de chamadas, os sumidouros de contaminação e os códigos decodificados, permitindo consultas como "quais drivers compartilham este código de controle específico?" ou "quais manipuladores alcançam um sumidouro de cópia sem uma verificação de comprimento?".
• Validação Híbrida: O sistema integra análise de contaminação estática com resultados de execução simbólica (via ioctlance) para validar cruzadamente as descobertas, demonstrando que os dois métodos possuem pontos cegos complementares (ex: a contaminação estática perde códigos METHOD_NEITHER, enquanto a execução simbólica sofre com a explosão de caminhos).

Resultos

• Cobertura: O passo determinístico recuperou uma superfície de despacho para 21.708 drivers (80,1% do corpus). O caminho profundo de x64 rendeu 8,18 milhões de funções e 63.263 sumidouros de contaminação de entrada-bufferizada.
• Eficiência de Filtragem: Os filtros determinísticos (descritor permissivo + sumidouro não sanitizado) reduziram os 27.087 drivers para 330 manipuladores candidatos para enriquecimento via LLM.
• Desempenho do Modelo: O LLM classificou 135 dos 329 manipuladores enriquecidos como "críticos" e 159 como "altos". Os autores enfatizam que estas são hipóteses de priorização, não bugs confirmados, sem uma taxa de verdade reportada.
• Acordo entre Métodos: Em uma comparação com o ioctlance em uma amostra de 1.000 drivers, os dois métodos concordaram em 65% dos drivers sinalizados pelo motor simbólico. A discordância foi atribuída principalmente à incapacidade do motor simbólico de alcançar certos manipuladores (teto de alcançabilidade) em vez de erros de precisão.
• Teste Retrospectivo (Backtesting): Um teste retrospectivo contra CVEs conhecidos e o catálogo LOLDrivers mostrou que o ranking é eficaz dentro de seu escopo (ex: um manipulador vulnerável conhecido em nvlddmkm.sys rankeou no topo de 0,14%). No entanto, o sistema perdeu vulnerabilidades em drivers de framework (WDF/KMDF) onde a entrada é recuperada via mecanismos diferentes não cobertos pela fonte de contaminação de entrada-bufferizada.

Significância e Alegações
O artigo reivindica significância não como um detector de vulnerabilidades que prova a existência de novos bugs, mas como um mapa fundamental da superfície de códigos de controle do Windows.

• Mudança da Detecção para a Navegação: Os autores argumentam que a comunidade precisa de um registro persistente e consultável da superfície de ataque para priorizar recursos escassos de engenharia reversa. O censo permite que pesquisadores naveguem na "cauda longa" dos drivers distribuídos em vez de depender da sorte ou de alvos selecionados manualmente.
• Democratização do Acesso: Ao liberar os dados estruturais (decodificação, grafos de chamadas, alcançabilidade) enquanto retém o nível de direcionamento específico (sumidouros de contaminação e vereditos de modelos) para evitar exploração de duplo uso, os autores visam baixar a barreira de entrada para a análise de segurança de drivers.
• Complementaridade: O trabalho demonstra que a recuperação determinística e a execução simbólica são complementares; o censo fornece o contexto estrutural que permite que esses métodos verifiquem uns aos outros e cubram pontos cegos.
• Trabalhos Futuros: Os autores reconhecem limitações, incluindo a falta de análise de contaminação para x86 e arm64, a exclusão de caminhos METHOD_NEITHER e de E/S direta, e a incapacidade de lidar com descritores de dispositivo aplicados em tempo de execução. Eles enquadram o censo como uma infraestrutura viva que pode ser estendida com novos analisadores (ex: para drivers de framework ou primitivas de memória física) sem reconstruir o núcleo.