CVE-2019-1429

Vulnerabilidade de execução remota de código no mecanismo de scripts do Internet Explorer (IE 9, 10 e 11), causada por corrupção de memória do tipo use-after-free na forma como o scripting engine lida com objetos. Está no catálogo KEV da CISA como exploração confirmada em campo, o que eleva sua prioridade de correção mesmo em um produto — IE — que a própria Microsoft já trata como legado.

A CISA classifica a falha sob CWE-416 (use-after-free) e CWE-787 (out-of-bounds write), o padrão clássico de bugs de scripting engine em navegadores da era pré-sandbox moderna: um objeto de script é liberado da memória enquanto uma referência a ele ainda é usada em outro ponto do código do engine, permitindo que um atacante realoque memória controlada no espaço liberado e depois acione a referência obsoleta para corromper o heap.

O ponto de disparo está na lógica interna do scripting engine do IE (o motor que interpreta JScript/VBScript embutido em páginas HTML), não em uma API específica exposta ao desenvolvedor web comum — a vulnerabilidade é ativada por sequências de script malformadas ou por manipulação de DOM/objetos que induzem o engine a um estado inconsistente de gerenciamento de memória. A Microsoft não publicou detalhes de código-fonte, e o advisory da MSRC segue o texto padrão de 'Scripting Engine Memory Corruption Vulnerability' sem especificar a rotina exata.

O atacante controla o conteúdo da página/script malicioso e, em exploits reais, tipicamente também precisa controlar a técnica de heap grooming para tornar a corrupção explorável de forma confiável — isso explica o AC:High no vetor CVSS, já que a exploração bem-sucedida (não apenas o crash) exige preparação cuidadosa de memória, distinta de uma falha trivialmente determinística.

O vetor é rede (AV:N): o atacante hospeda ou injeta conteúdo malicioso em uma página web e depende de interação do usuário (UI:R) — a vítima precisa abrir a página no Internet Explorer, seja diretamente, seja via um link em e-mail, documento com renderização IE embutida, ou anúncio malicioso. Não é necessário nenhum privilégio prévio (PR:N) nem autenticação.

A complexidade de ataque é alta porque o use-after-free por si só gera apenas corrupção de memória; transformar isso em execução de código confiável exige bypass de mitigações de heap e técnicas de vazamento de informação para calcular endereços, o que normalmente é encapsulado em um exploit kit ou cadeia de exploração mais ampla. A presença de PoC pública (referenciada no PacketStorm como 'Internet Explorer Use-After-Free') reduz a barreira para reprodução do crash, mas não significa necessariamente exploit de RCE turnkey.

A CISA confirma exploração ativa em campo (por isso a entrada no KEV), mas os detalhes de campanha, atores ou contexto de uso não constam nas fontes disponíveis. O resultado final, quando bem-sucedido, é execução de código no contexto do usuário atual — ou seja, se a vítima estiver logada como administrador, o impacto é total (C:H/I:H/A:H); se for usuário com privilégios limitados, o atacante herda essas mesmas limitações e normalmente busca uma escalação de privilégios subsequente.

A correção veio pelas atualizações de segurança da Microsoft do ciclo de novembro de 2019 (mesma data de publicação da CVE, 12/11/2019 — Patch Tuesday), aplicadas via Windows Update/WSUS para as versões afetadas do Internet Explorer 9, 10 e 11, incluindo os ramos de Windows Server 2012 e Windows 10 versão 1903 (32-bit, x64 e ARM64) listados pela Microsoft. Não temos nas fontes o número exato do KB/boletim, então não reproduza um número aqui — confirme a atualização aplicável pelo Windows Update ou pelo Microsoft Update Catalog filtrando por CVE-2019-1429.

Como paliativo real, quando a atualização não pode ser aplicada imediatamente: reduzir a superfície de exposição do IE é a medida mais efetiva — configurar Enhanced Protected Mode, restringir ou desabilitar a execução de scripts em zonas de segurança não confiáveis, e sobretudo migrar o uso cotidiano de navegação para um navegador com engine ativamente mantido, já que a Microsoft descontinuou o desenvolvimento do IE. Desabilitar completamente o scripting engine (jscript/vbscript) quebra a maioria dos sites legados que ainda dependem de IE em ambientes corporativos, então esse controle tem custo operacional real e deve ser avaliado caso a caso.

Não funciona como mitigação: apenas atualizar o Windows Defender/antivírus, sem aplicar o patch do IE, não neutraliza a falha — é corrupção de memória no engine, não malware detectável por assinatura antes da exploração. Da mesma forma, políticas de bloqueio de macro/anexo não cobrem o vetor, que é conteúdo web renderizado pelo próprio IE.

Não há assinatura de rede confiável e específica publicada nas fontes disponíveis, já que a exploração ocorre inteiramente no lado do cliente via script malicioso renderizado pelo IE. Sinais indiretos a observar incluem crashes ou travamentos anômalos do processo iexplore.exe/jscript9.dll (ou wow64 equivalents) em endpoints, especialmente correlacionados com navegação a domínios recém-registrados ou incomuns, e logs de EDR mostrando IE gerando processos filho inesperados após visita a uma página — padrão típico de exploração de UAF seguida de execução de payload.