CVE-2015-2291

Falha de validação de entrada no driver de diagnóstico Ethernet da Intel para Windows (IQVW32.sys/IQVW64.sys) permite que um usuário local, sem privilégios elevados, cause um crash do kernel (BSOD) e, segundo o pesquisador que a reportou, potencialmente execute código em modo kernel. Importa porque esse driver historicamente ficava instalado com permissões de acesso abertas a qualquer usuário do sistema ("everyone read/write"), eliminando a barreira de privilégio que normalmente protegeria uma interface kernel — e está no catálogo KEV da CISA com exploração confirmada, embora a CISA classifique o impacto observado como negação de serviço, não RCE.

O driver iqvw32.sys/iqvw64e.sys expõe um device object acessível via IOCTL para funções de diagnóstico da placa de rede Intel. Quatro códigos de controle — 0x80862013, 0x8086200B, 0x8086200F e 0x80862007 — são processados usando o método de transferência METHOD_NEITHER, no qual o driver recebe diretamente os ponteiros brutos fornecidos pelo usuário (Type3InputBuffer/Type3OutputBuffer) sem que o I/O Manager valide ou copie a memória antes. Isso é um caso clássico de CWE-20 (Improper Input Validation, listado pela própria CISA): o driver assume que os ponteiros passados pelo espaço de usuário são válidos e os desreferencia sem checagem de faixa ou de acessibilidade.

O PoC público (Exploit-DB 36392) mostra que basta abrir um handle para o device do driver e enviar um DeviceIoControl com um dos IOCTLs vulneráveis e um valor de ponteiro arbitrário (o crash dump demonstrado usa o valor sentinela 0xdeadbeef) para provocar uma leitura de memória inválida em contexto kernel. O resultado documentado é bugcheck 0x3B (SYSTEM_SERVICE_EXCEPTION) com a falha ocorrendo dentro de iqvw64e.sys ao executar 'mov rdx, qword ptr [rcx]' sobre um ponteiro controlado pelo atacante — ou seja, uma negação de serviço garantida e reproduzível. A afirmação de execução de código em kernel é do pesquisador (Glafkos Charalambous) como possibilidade teórica dado o controle sobre o ponteiro desreferenciado; não há PoC público demonstrando RCE completo, e a CISA descreve a falha no KEV apenas como vulnerabilidade de DoS.

A mitigação definitiva é atualizar o driver de diagnóstico Ethernet da Intel para a versão 1.3.1.0 ou posterior (IQVW32.sys e IQVW64.sys), conforme o advisory INTEL-SA-00051. Como paliativo em ambientes que não podem atualizar imediatamente, restringir as permissões de acesso ao device object do driver — de modo que apenas processos com privilégio administrativo possam abri-lo — reduz a superfície, já que parte do problema apontado pelo pesquisador é justamente a permissão aberta a qualquer usuário; esse controle compensatório não corrige a falha de validação, apenas eleva o pré-requisito de privilégio para explorá-la. Não existe mitigação via rede ou WAF, pois o vetor é estritamente local (IOCTL); soluções de filtragem de tráfego não têm efeito.

Em nível de host, indício de tentativa de exploração é uma pilha de crash (bugcheck 0x3B, SYSTEM_SERVICE_EXCEPTION) com o módulo faltante iqvw64e.sys/iqvw32.sys no topo da pilha e a falha originada em NtDeviceIoControlFile — dumps de memória do kernel (minidump/kernel dump) mostrando isso são o sinal mais confiável. Como o vetor é uma chamada IOCTL local para um device driver, não há sinal de rede a monitorar; ferramentas de auditoria de chamadas de sistema ou ETW que capturem DeviceIoControl com os códigos 0x80862013, 0x8086200B, 0x8086200F ou 0x80862007 endereçados ao device do driver de diagnóstico Intel são a única telemetria direta disponível, e a maioria dos ambientes não tem esse nível de instrumentação habilitado por padrão.