CVE-2008-3431

Falha de validação de entrada no driver de kernel VBoxDrv.sys do VirtualBox (então Sun xVM VirtualBox) para hosts Windows, que permite a um usuário local sem privilégios executar código arbitrário em modo kernel e escalar para privilégios de SYSTEM/kernel. Importa porque VirtualBox era (e é) amplamente usado em estações de desenvolvimento e laboratórios, e a exploração não exige nenhuma condição exótica — só acesso local à máquina onde o produto está instalado. Está no catálogo KEV da CISA, confirmando exploração real, ainda que a vulnerabilidade tenha 16+ anos e afete apenas versões antigas descontinuadas.

O ponto de falha é a função VBoxDrvNtDeviceControl em VBoxDrv.sys (arquivo fonte SUPDrv-win.cpp), responsável por tratar as requisições IOCTL enviadas pelo espaço de usuário ao driver. Os IOCTLs de 'fast path' (SUP_IOCTL_FAST_DO_RAW_RUN, SUP_IOCTL_FAST_DO_HWACC_RUN, SUP_IOCTL_FAST_DO_NOP) são registrados com o método de buffering METHOD_NEITHER do I/O Manager do Windows.

METHOD_NEITHER é o modo mais perigoso de comunicação IOCTL porque o I/O Manager não copia nem valida os buffers de entrada/saída — ele simplesmente passa ao driver o ponteiro bruto (pIrp->UserBuffer) que a aplicação de espaço de usuário informou em DeviceIoControl. A responsabilidade de validar se aquele endereço é legítimo e pertence ao espaço de usuário fica inteiramente a cargo do driver. O código de VBoxDrv.sys escreve o resultado da chamada diretamente nesse ponteiro (*(int *)pIrp->UserBuffer = rc) sem checar previamente se o endereço é válido, mapeado e pertence ao processo chamador.

Como qualquer usuário sem privilégios pode abrir o dispositivo \\.\VBoxDrv (não há controle de ACL restritivo) e chamar DeviceIoControl com esse IOCTL, o atacante controla o valor do 'buffer' passado como argumento — na prática, um endereço arbitrário de kernel. Isso permite usar o driver como uma primitiva de escrita arbitrária em memória de kernel, o que pesquisadores da CORE Security demonstraram ser suficiente para corromper estruturas de kernel e executar código com privilégios de kernel. O CVE é catalogado sob CWE-264 (controle de acesso/privilégios impróprio) pela CISA, embora a causa raiz descrita pelos pesquisadores seja melhor enquadrada como validação de entrada insuficiente (CWE-20) aplicada a um buffer de IOCTL não confiável.

O vetor é estritamente local: o atacante precisa de uma sessão no host Windows onde o VirtualBox vulnerável está instalado, sem necessidade de privilégios administrativos prévios (PR:L no vetor CVSS informado reflete apenas a necessidade de estar logado como usuário comum). Não há componente de rede — o exploit interage diretamente com o dispositivo de driver \\.\VBoxDrv via DeviceIoControl.

A CORE Security Technologies (créditos a Anibal Sacco) publicou o advisory coordenado (CORE-2008-0716) junto com uma prova de conceito (disponível no Exploit-DB, EDB-ID 6218) que demonstra a técnica: abrir o device, montar o IOCTL de fast-path com um endereço de kernel forjado como 'buffer' e observar a escrita não validada. A complexidade é baixa uma vez que se conhece o mecanismo — não há necessidade de bypass de ASLR/DEP relevantes para a época, já que a própria interface do driver entrega a primitiva de escrita.

O resultado final documentado é execução de código arbitrário em modo kernel, com controle total do sistema operacional host — não apenas da VM. A presença no catálogo KEV da CISA confirma exploração ativa reportada, embora sem detalhes públicos de campanhas específicas; a natureza da falha (privesc local em software de virtualização) a torna atrativa como etapa de pós-exploração para elevar privilégios após um comprometimento inicial de baixo privilégio.

A correção do fornecedor é atualizar para Sun xVM VirtualBox 1.6.4 ou posterior nas instalações Windows — a própria advisory da CORE Security afirma explicitamente que não existe workaround/configuração de mitigação para essa falha enquanto a versão vulnerável estiver instalada. O boletim de segurança da Sun (SunSolve, referenciado nas fontes) trata o mesmo caso.

Como a falha está no driver de kernel e o dispositivo pode ser aberto por qualquer usuário local, restringir ACLs do dispositivo \\.\VBoxDrv ou desabilitar/remover o serviço do driver em hosts onde o VirtualBox não está em uso ativo reduz a superfície, mas isso não é uma mitigação endossada pelo fornecedor — é controle compensatório de última instância até a atualização.

Não adianta restringir apenas o uso da interface gráfica do VirtualBox ou políticas de aplicação (AppLocker/whitelisting) sobre executáveis do produto: o vetor de ataque é a interação direta com o driver de kernel via DeviceIoControl, que não depende de nenhum binário específico do VirtualBox rodando — qualquer processo capaz de chamar a API do Windows serve. Dado a idade da falha (2008) e que versões atuais do VirtualBox usam uma arquitetura de driver completamente diferente, o remédio prático hoje é garantir que nenhuma instalação de VirtualBox anterior a 1.6.4 permaneça em produção.

Não há um sinal de rede a monitorar, já que a exploração é inteiramente local e ocorre via chamada direta à API do Windows (DeviceIoControl) contra o driver, sem tráfego de rede associado. Em nível de host, indícios possíveis incluem: processos incomuns de usuários não administrativos abrindo o handle \\.\VBoxDrv fora do fluxo normal de uso das ferramentas do VirtualBox (VirtualBox.exe, VBoxSVC.exe, VBoxHeadless.exe), crashes ou eventos de exceção registrados pelo driver (o próprio código trata excepões via __except e pode gerar entradas de debug/dprintf), e crashes do sistema (BSOD) inexplicados em hosts com VirtualBox vulnerável instalado — mas nenhuma dessas evidências é um indicador confiável e específico de exploração; a ausência de logging nativo do driver para tentativas de IOCTL malformado torna a detecção retroativa pouco viável sem instrumentação prévia (ETW, drivers de auditoria de kernel) no momento do ataque.