CVE-2010-0232

Falha de elevação de privilégio local no kernel NT do Windows (todas as versões 32-bit, de NT 3.1 até Windows 7), descoberta por Tavis Ormandy. Um usuário autenticado localmente pode forjar uma estrutura VDM_TIB e um trap frame para forçar o handler #GP (nt!KiTrap0D) a trocar o stack pointer do kernel por um endereço controlado pelo atacante, ganhando execução em contexto kernel. Não é explorável remotamente nem por usuário anônimo — exige logon local válido —, mas uma vez atingido esse pré-requisito a exploração é confiável e há PoC pública e módulo Metasploit.

O subsistema NTVDM (Virtual DOS Machine) existe para permitir que aplicações 16-bit legadas façam chamadas de BIOS em modo Virtual-8086 sobre um kernel 32-bit. Essas chamadas são implementadas em dois estágios: o kernel transiciona para o segundo estágio quando o #GP trap handler (nt!KiTrap0D) detecta que o par cs:eip da falha corresponde a valores 'mágicos' específicos do subsistema BIOS. A transição restaura contexto de execução e call stack a partir do trap frame previamente salvo, presumindo que esse trap frame é confiável.

Ormandy identificou três premissas de segurança quebradas nessa validação. Primeiro, configurar um contexto VDM (via NtVdmControl) deveria exigir SeTcbPrivilege — mas essa checagem só é feita no momento de setar o flag VdmAllowed no EPROCESS, e um processo sem esse privilégio pode usar CreateRemoteThread() para injetar uma thread no processo ntvdm.exe já existente, que já tem o flag setado. Segundo, código ring3 não deveria conseguir instalar seletores de segmento de código arbitrários — mas o modo Virtual-8086 exige endereçamento segmentado (cs << 4 + eip), e o par cs específico necessário para o exploit passa pela validação de PsSetLdtEntries. Terceiro, código ring3 não deveria conseguir forjar um trap frame — mas usando o VdmContext instalado via NtVdmControl(), é possível construir um contexto inválido que faz a instrução iret falhar no estágio pré-commit, deixando um trap frame forjado utilizável.

O resultado é que, ao chamar NtVdmControl(VdmStartExecution, NULL) com o TEB preparado (SegCs = 0x0B, Esi apontando para uma stack falsa, Eip apontando para o endereço mágico de retorno da BIOS call), o código em Ki386BiosCallReturnAddress restaura ESP a partir do trap frame não confiável (mov esp, [ebp+KTRAP_FRAME.Esi]), efetivamente trocando o kernel stack pointer para o endereço escolhido pelo atacante. A partir daí o atacante controla execução em contexto kernel.

Em sistemas com ASLR de kernel (Vista em diante), o exploit precisa prever o endereço de Ki386BiosCallReturnAddress; isso é trivialmente contornado localmente porque qualquer usuário não privilegiado pode consultar a lista de módulos carregados via NtQuerySystemInformation, o que neutraliza essa mitigação nesse cenário específico.

A exploração é 100% local: exige que o atacante já tenha credenciais válidas e possa fazer logon interativo (ou executar código) na máquina — não há vetor remoto ou anônimo. A pré-condição adicional, muitas vezes omitida em resumos da falha, é que o acesso a aplicações 16-bit precisa estar habilitado no sistema 32-bit; em várias instalações corporativas isso pode já estar desativado por política.

Com essas condições satisfeitas, o atacante cria/usa um processo ntvdm.exe (que carrega o subsistema DOS/WOWEXEC), injeta uma thread nele via CreateRemoteThread para herdar o flag VdmAllowed, monta a estrutura VDM_TIB forjada dentro do TEB da thread e dispara NtVdmControl para iniciar a execução da VDM. Isso aciona o caminho de código vulnerável no #GP trap handler, que troca o stack do kernel para um endereço controlado pelo atacante, levando a execução arbitrária em modo kernel — resultado final: elevação de privilégio de usuário comum para SYSTEM/kernel.

A vulnerabilidade está no catálogo KEV da CISA (exploração confirmada em uso), existe módulo Metasploit e PoC pública (KiTrap0D.zip, do próprio Ormandy), testado por ele em XP, Server 2003/2008, Vista e Windows 7 32-bit. Não há indicação de exploração remota nem de bypass de autenticação — o valor do exploit está em escalar privilégios após comprometimento inicial (malware, shell de baixo privilégio, usuário convidado etc.).

O fornecedor corrigiu a falha via MS10-015 (publicado em 09/02/2010), que também resolve uma segunda vulnerabilidade de elevação de privilégio reportada de forma privada e o problema descrito no Security Advisory 979682. A recomendação é aplicar essa atualização de segurança nas versões afetadas assim que possível.

Se a atualização não puder ser aplicada de imediato, o próprio pesquisador descreve um paliativo real: desabilitar o acesso a aplicações 16-bit usando o modelo de política de grupo 'Windows Components\Application Compatibility\Prevent access to 16-bit applications'. Isso impede a criação do processo NTVDM com o subsistema MSDOS/WOWEXEC habilitado e, sem um processo com VdmAllowed setado, não é possível acessar NtVdmControl() sem SeTcbPrivilege — quebrando a cadeia de exploração na primeira premissa. O custo é a perda de suporte a aplicações DOS/16-bit legadas no host, o que pode ser inaceitável em ambientes com dependências legadas.

O ASLR de espaço de kernel (introduzido no Vista) não funciona como mitigação eficaz aqui: como o próprio artigo aponta, qualquer usuário não privilegiado pode consultar o endereço do módulo via NtQuerySystemInformation e recuperar o endereço necessário — não é um controle compensatório confiável contra esse exploit específico. A única mitigação sólida sem o patch é desabilitar 16-bit apps via GPO; a atualização MS10-015 é a correção definitiva.

Por se tratar de exploração puramente local em kernel, não há assinatura de rede a procurar. Sinais possíveis em telemetria de endpoint/EDR: criação do processo ntvdm.exe seguida de CreateRemoteThread nesse processo por outro processo não relacionado ao subsistema DOS; chamadas à API NtVdmControl fora do fluxo normal de inicialização de aplicações 16-bit; e crashes ou comportamento anômalo do kernel (BSOD) associados a nt!KiTrap0D em máquinas onde 16-bit apps não deveriam estar em uso. Não existe um indicador de comprometimento único e confiável publicado pelo fornecedor ou pesquisadores para esta falha — a ausência de assinatura forte é, em si, a informação relevante: detecção depende de monitoramento de comportamento de processo, não de padrão de tráfego ou payload fixo.