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

Resumo Técnico: O Censo de IOCTL do Linux

Definição do Problema
A chamada de sistema ioctl serve como a principal interface de controle de dispositivos do Linux, permitindo que programas do espaço do usuário enviem códigos de comando numéricos e buffers de argumentos para drivers do kernel. Embora essencial para a configuração de hardware e gerenciamento de estado, esta interface representa uma superfície de ataque vasta, heterogênea e mal catalogada localmente. Drivers definem milhares de comandos únicos, muitas vezes processando argumentos em contexto de kernel sem validação uniforme. Um manipulador que confia em um comprimento de argumento não validado pode levar a leituras ou escritas de memória fora dos limites (out-of-bounds).

Abordagens atuais para analisar esta superfície são fragmentadas:

• Scanners Dinâmicos (ex: syzkaller): Eficazes na descoberta de bugs de tempo de execução e condições de corrida, mas limitados ao espaço de comando específico que lhes é explicitamente instruído a exercitar. Eles reportam bugs disparados, não o espaço de comando não explorado.
• Curadoria Manual: Listas como o catálogo de LPE de alcance não privilegiado e documentação de modelagem de ameaças existem como prosa mantida manualmente, não como enumerações sistemáticas e consultáveis do espaço de comando decodificado.

Há uma falta de um inventário persistente, derivado da fonte, que mapeie todo o espaço de comando estático, incluindo despachadores, comandos decodificados, manipuladores e portões de permissão.

Metodologia: Extrair-Portão-Classificar (Extract-Gate-Rank)
Os autores apresentam um pipeline determinístico, Extract-Gate-Rank, que lê o código-fonte do kernel Linux para materializar um banco de dados relacional da superfície de ioctl. O processo opera em um build allmodconfig (x86_64) cobrindo 878 módulos em 169 subárvores.

1. Extrair (Extract):

   • Utiliza um grafo de conhecimento derivado de libclang do código-fonte do kernel para identificar despachadores de ioctl (funções vinculadas a unlocked_ioctl, compat_ioctl ou proc_ops.proc_ioctl).
   • Percorre os fechamentos de chamada até os corpos dos manipuladores por comando.
   • Decodifica Códigos de Comando: Um resolvedor expande macros _IOC contra cabeçalhos UAPI para decodificar códigos de comando de 32 bits em quatro campos: direção, tamanho, byte mágico e ordinal.
   • Identifica Sinks e Portões: Registra sinks de entrada controlada (ex: copy_from_user) dentro de uma janela de salto de chamada fixa e portões de permissão (verificações de capacidade, ganchos LSM, verificações de f_mode).
   • Heurística de Sanitização: Marca um sink como "não sanitizado" se nenhum check de limites rígidos preceder o mesmo na ordem de origem da função. Esta é uma proxy estrutural, não uma prova de fluxo de controle.

2. Portão (Gate):

   • Aplica um filtro de alcançabilidade de modelo de ameaça como uma coluna consultável.
   • Um módulo é marcado como capability_ungated se seu caminho de ioctl carece de um portão de capacidade de init-namespace rígido (ex: CAP_SYS_ADMIN).
   • Isso atua como um limite superior de condição necessária para o alcance não privilegiado, não como um classificador de abertura de nó real. Exclui drivers de staging e caminhos de debugfs conforme a documentação do kernel.

3. Classificar (Rank):

   • Gera visões relacionais sobre o armazenamento, priorizando despachadores sem portões de capacidade com sinks não sanitizados.
   • Inclui uma visão cross-module agrupando códigos de comando compartilhados (tipo, ordinal, acesso) através de diferentes drivers.
   • Uma camada de enriquecimento por LLM opcional é incluída para triagem, mas é mantida fora do caminho crítico e em um nível retido.

Principais Resultados
O censo cobre o build allmodconfig x86_64 (84% dos arquivos de fonte in-tree) e inclui um build secundário arm64 para validação.

• Escala: A análise recuperou 586 pontos de entrada de despacho de ioctl em 337 módulos, decodificando 1.289 códigos de comando _IOC únicos.
• Sinks e Portões: Identificou 3.583 sinks de entrada controlada e 1.298 portões de permissão.
• Alcançabilidade: O filtro de modelo de ameaça excluiu 50 módulos atrás de portões rígidos de capacidade, admitindo 281 módulos como o limite superior não-restrito de alcance não privilegiado.
• Cobertura de Arquitetura: Um segundo build para arm64 adicionou apenas um módulo único (Apple adp_drv) e nenhum novo código de comando, indicando que o x86_64 cobre 99,7% dos módulos que possuem ioctl.
• Compartilhamento de Comando: Padrões de comando compartilhados (ex: comandos WDIOC_* de watchdog) recorrem em múltiplos drivers, sugerindo que uma vulnerabilidade em um padrão compartilhado pode afetar muitos módulos simultaneamente.
• Concentração de Capacidade: Os portões de permissão são dominados por CAP_SYS_ADMIN (512 ocorrências), uma capacidade que o modelo de ameaça do kernel trata explicitamente como "fora do modelo", estreitando ainda mais a superfície de ataque em escopo.

Validação de Backtest
Os autores validaram o censo contra 22 CVEs recentes de ioctl in-tree:

• Cobertura: Todos os 22 CVEs caíram dentro de subárvores cobertas, eliminando lacunas de cobertura como fonte de erro.
• Recuperação: A passagem de recuperação de despachador encontrou o manipulador vulnerável para 7 dos 22 CVEs.
• Omissões: As 15 omissões foram inteiramente atribuíveis a limitações do modelo de registro:
  • 8 casos envolveram núcleos DRM/V4L2 usando despacho de tabela de operações (drm_ioctl_desc, vl2_ioctl_ops) onde o núcleo copia argumentos antes de passá-los para os manipuladores por comando.
  • 3 casos envolveram disciplinas de linha tty.
  • 4 casos foram funções alcançadas apenas como chamadas abaixo do despachador, não o próprio despachador.
• Precisão do Filtro: O filtro admitiu corretamente todos os 7 CVEs encontrados. Dois foram "falsos admitidos" em relação a restrições de node-DAC (Controle de Acesso de Dispositivo) (ex: pci_endpoint_test), o que o método prevê corretamente como uma limitação, pois não analisa permissões de nós de dispositivo, apenas portões de capacidade.

Significância e Alegações
O artigo posiciona o Linux IOCTL Census como uma contribuição de medição e dataset em vez de uma ferramenta de busca de bugs. Sua principal significância reside em:

1. Persistência e Consultabilidade: Transforma a superfície de ioctl de uma lista transitória de bugs em um repositório relacional persistente e consultável. Isso permite que auditores façam perguntas estruturais (ex: "Quais módulos compartilham este código de comando?") que listas de bugs não podem responder.
2. Integração de Modelo de Ameaça: Codifica o modelo de ameaça documentado do kernel diretamente no esquema de dados, transformando fronteiras de segurança baseadas em prosa em filtros consultáveis.
3. Complementaridade: Complementa o fuzzing dinâmico ao enumerar todo o espaço de comando estático, incluindo comandos que podem carecer de harnesses ou descrições, orientando assim ferramentas dinâmicas para áreas não exploradas.
4. Esquema Cross-OS: O dataset compartilha um esquema com o censo complementar de Windows IOCTL, permitindo consultas cross-platform.

Limitações
Os autores declaram explicitamente vários limites:

• Alcançabilidade: O contador "acessível pelo usuário" é um limite superior baseado em portões de capacidade, não uma prova de abertura de nó (DAC).
• Sanitização: O contador "não sanitizado" é uma proxy heurística baseada na ordem da fonte, não uma prova formal de segurança.
• Cobertura: É limitada ao que um build allmodconfig compila; outras arquiteturas e drivers que não podem ser habilitados simultaneamente são excluídos.
• Modelo de Registro: O modelo atual perde manipuladores registrados via tabelas de operações (DRM, V4L2, ALSA), disciplinas de linha tty e funções auxiliares abaixo do despachador.

O dataset é liberado em dois níveis: um nível estrutural público (módulos, despachadores, códigos, portões) sob uma licença aberta, e um nível de direcionamento retido (localizações específicas de sinks, vereditos de enriquecimento e superfície não privilegiada classificada) para evitar a exploração de duplo uso, enquanto suporta a pesquisa autorizada.