CVE-2016-7255

Falha de elevação de privilégio local nos drivers em modo kernel do Windows (win32k.sys), presente desde o Windows Vista SP2 até o Windows 10 1607/Server 2016. Foi usada como zero-day em exploração ativa antes da correção — revelada pela Google (Threat Analysis Group) em outubro de 2016 junto com um 0-day do Flash, formando uma cadeia de escape de sandbox — e está no catálogo KEV da CISA. O CVSS 7.8 reflete o impacto (execução com privilégios de SYSTEM), mas o vetor é local: exige execução de código já no sistema, não é uma falha remota.

A vulnerabilidade está no manuseio de objetos em memória pelos drivers em modo kernel do subsistema de janelas do Windows (win32k.sys), o mesmo componente que processa mensagens de janela e menus para todo processo com sessão gráfica. Segundo a divulgação da Google, o bug é acionado pela chamada de sistema NtSetWindowLongPtr() usando o índice GWLP_ID sobre um handle de janela cujo GWL_STYLE está marcado como WS_CHILD.

A falha decorre de o kernel confiar em um estado de janela (o bit de estilo WS_CHILD) que pode ser manipulado ou observado em um momento inconsistente pelo código de validação, permitindo que uma escrita destinada a um campo (ID de controle filho) afete efetivamente outro campo da mesma estrutura de janela que normalmente seria interpretado como um handle de menu (HMENU) — os dois compartilham a mesma posição de memória na estrutura interna, dependendo do tipo de janela. Isso corrompe o estado interno do objeto de janela de forma que o atacante controla, abrindo caminho para corrupção de memória controlada em contexto kernel.

O boletim MS16-135 da Microsoft descreve genericamente a correção como ajuste de "como o driver em modo kernel do Windows manipula objetos na memória", sem detalhar a mecânica exata — a análise técnica pública (Google, Trend Micro, McAfee, MWR Labs) é que preenche essa lacuna. O atacante não precisa de acesso à rede: precisa apenas rodar uma aplicação já autenticada localmente (ou obter execução de código por outro vetor) para acionar a chamada de sistema maliciosa.

O pré-requisito real é execução de código local — a aplicação maliciosa roda como usuário padrão/com poucos privilégios e usa a chamada NtSetWindowLongPtr com os parâmetros específicos (GWLP_ID sobre janela com estilo WS_CHILD) para corromper o estado do objeto de janela no kernel. A partir daí a cadeia de exploração manipula esse estado corrompido para obter execução de código arbitrário em contexto kernel, resultando em SYSTEM.

Na prática documentada, foi explorada como parte de uma cadeia com um 0-day do Adobe Flash (CVE-2016-7855): o Flash dava execução de código no contexto do processo/navegador, e o CVE-2016-7255 escalava daí para o kernel, servindo como escape de sandbox — inclusive do sandbox do Chrome, que a própria Google notou ser bloqueado nesse cenário específico no Windows 10 pela mitigação Win32k lockdown. Existem PoCs públicos (MWR Labs/F-Secure Labs no GitHub, Exploit-DB, Packet Storm) que reproduzem o comportamento descrito pela Trend Micro no exploit encontrado in the wild, cobrindo Windows 7/8/8.1/10 pré-Anniversary Update em 64 bits.

A complexidade de exploração é considerada baixa a moderada para quem já tem um PoC funcional — não exige interação do usuário além de executar o binário malicioso, e não depende de configuração não padrão do Windows. O uso real documentado foi como segundo estágio dentro de uma campanha direcionada, não como exploração em massa oportunista.

A correção oficial é o boletim MS16-135 (KB3199135), lançado em 8 de novembro de 2016, que atualiza os drivers em modo kernel do Windows. Os pacotes variam por versão: KB3198234 para Windows Vista SP2/Server 2008 SP2, KB3197867 (security-only) ou KB3197868 (monthly rollup) para Windows 7 SP1/Server 2008 R2 SP1, KB3197873/3197874 para Windows 8.1/Server 2012 R2, com pacotes equivalentes para Server 2012, RT 8.1, Windows 10 (Gold, 1511, 1607) e Server 2016 — aplicar a atualização cumulativa de novembro/2016 correspondente à versão em uso resolve o problema.

Como esses sistemas estão fora de suporte há anos, o paliativo real hoje é isolar ou desativar completamente qualquer host Vista/Server 2008/7/8.1/2012 que ainda rode sem esse patch — não há como mitigar via configuração de win32k sem quebrar funcionalidade de UI, já que a falha está no próprio driver gráfico do kernel. Controles compensatórios eficazes incluem AppLocker/WDAC restringindo execução de binários não assinados (reduz a chance de a aplicação maliciosa inicial rodar) e, em ambientes de navegador, mitigações de Win32k lockdown (disponíveis a partir do Windows 10), que bloqueiam chamadas de sistema win32k.sys vindas de processos em sandbox e cortam essa via de escape especificamente.

Não funciona como mitigação: qualquer controle de rede (firewall, IPS de perímetro), já que a falha não tem componente remoto — é puramente local pós-execução de código.

Não há assinatura de rede aplicável, pois a exploração é inteiramente local. Em endpoint, o sinal a procurar é uma aplicação de usuário sem privilégio elevado que faça chamadas diretas e atípicas ao subsistema win32k (NtUserSetWindowLongPtr/NtSetWindowLongPtr) fora do padrão normal de uso de GUI, especialmente processos que não deveriam manipular estilos de janela (ex.: processos de rendering de plugin/navegador logo após execução de conteúdo suspeito) seguidos de crash ou elevação abrupta de token para SYSTEM.

Como o exploit conhecido foi usado em conjunto com um 0-day do Flash dentro de navegadores, EDRs modernos com telemetria de ETW para win32k e detecção de escalonamento de token/criação de processo SYSTEM a partir de processo de baixo privilégio são o sinal prático mais confiável disponível — não existe IOC de arquivo ou hash fixo, já que os PoCs e a variante in the wild podem ser recompilados livremente.