Como obter CVEs com rigor técnico: análise de drivers ASUS revela dois bugs críticos

O que Jeff Barron fez não foi só encontrar dois CVEs, ele aplicou um método reprodutível de caça a vulnerabilidades em drivers Windows com rigor técnico raro na era da IA. Ele usou Claude Code como assistente de engenharia reversa dentro do Ghidra MCP, mas o verdadeiro trabalho foi humano: criar a ferramenta cthaeh para priorizar drivers não analisados (evitando os já batidos da Microsoft), forçar a IA a gerar PoCs funcionais, não apenas descrições plausíveis, e validar cada passo no modo kernel com controle total sobre o fluxo de memória e permissões.

A CVE-2026-3508 é um clássico erro de validação de tamanho: o driver AsusWmiAcpi.sys confia cegamente no campo InBufferSize de uma requisição IOCTL METHOD_BUFFERED, sem verificar se o buffer real fornecido pelo sistema tem aquela capacidade. O resultado? Leitura arbitrária de até 0x400 bytes além do fim do buffer, suficiente para causar BSOD, mas não para vazar dados sensíveis ou executar código. Já a CVE-2026-6737 é mais sutil: o driver AsusPTPFilter.sys cria objetos de dispositivo nomeados sem SDDL explícito, herdando permissões padrão que permitem a qualquer usuário local abrir o device e disparar quatro IOCTLs privilegiados, incluindo leitura de strings internas e escrita em estado fixo. Isso viola o princípio de menor privilégio no kernel Windows desde a NT 4.0.

A CEVIU já havia mostrado, em maio, que LLMs podem gerar exploits funcionais em FreeBSD (CVE-2026-4747) e encadear primitivas em firmware UEFI (LogoFail). Mas Barron trouxe algo novo: um workflow operacional para drivers Windows, com ferramenta própria de triagem (cthaeh) e foco em bugs reais de exploração prática, não só de impacto teórico. Antes, os relatos eram de 'IA achou algo'; agora, é 'IA ajudou a provar exatamente onde e como falha'. Também há mudança de escala: enquanto o Project Glasswing da Cloudflare testou Mythos em repositórios, Barron rodou tudo localmente, em cinco VMs Proxmox, com MCP orquestrando Ghidra, WinDbg e compiladores, o mesmo setup descrito na cobertura de 13/05 sobre caça autônoma de vulnerabilidades.

Essas duas CVEs são um alerta direto para PSIRTs de fabricantes de hardware: drivers de suporte (como os da ASUS) são alvos fáceis de BYOVD (Bring Your Own Vulnerable Driver), técnica usada em ataques avançados para escapar de sandbox e ganhar privilégios de kernel. A CVE-2026-6737, mesmo com CVSS 2.0, é particularmente perigosa porque permite que um atacante local, sem privilégios administrativos, manipule diretamente o subsistema de touchpad, abrindo portas para persistência, coleta de dados de interação ou até desabilitação silenciosa de controles de segurança física. Para equipes de defesa, o caso mostra que auditorias de drivers devem exigir análise estática *comparativa* de permissões de dispositivos e validação de buffers, não apenas fuzzing cego. E para desenvolvedores, reforça: IoCreateDevice sem SDDL é tão inseguro quanto strcpy em código de usuário.