Scripting Engine Memory Corruption Vulnerability

Falha de corrupção de memória no motor de script jscript9.dll, usado pelo Internet Explorer 11, que permite execução remota de código no contexto do usuário atual. O CVSS de 7.8 (exploração local, sem privilégio elevado necessário) subestima o risco real de uso em cadeia: pesquisadores documentaram exploração ativa combinando essa falha com uma elevação de privilégio no kernel do Windows, resultando em comprometimento total do sistema a partir de uma simples visita a uma página maliciosa.

A vulnerabilidade está classificada pela CISA como CWE-787 (Out-of-bounds Write). O problema ocorre no jscript9.dll, o motor JavaScript legado usado pelo Internet Explorer 11, na forma como objetos são gerenciados em memória durante a execução de script. Um atacante que controla o conteúdo de uma página web (ou de um documento que hospeda o motor de renderização do IE) pode manipular estruturas de objetos de forma a corromper memória heap, criando condições para escrita fora dos limites alocados.

A descrição oficial da Microsoft é deliberadamente vaga sobre o mecanismo exato — não especifica qual objeto ou API do jscript9.dll está envolvida. Isso é típico de advisories de scripting engine da era pré-Chromium do IE, onde a Microsoft historicamente evitou detalhar internals do motor. O arquivo referenciado no PacketStorm ("jscript9.dll Memory Corruption") confirma o componente específico, mas o writeup técnico completo de como a corrupção é disparada não está disponível nas fontes consultadas aqui.

O atacante controla o script executado no contexto da página renderizada — ou seja, todo o conteúdo JavaScript/ActiveX que dispara a condição de corrupção. Como o CVSS indica AV:L (vetor local), a exploração via web na prática se dá através da renderização de conteúdo controlado pelo atacante dentro do processo do IE no sistema da vítima, não através de rede diretamente.

O vetor primário é web-based: uma página maliciosa hospedada pelo atacante, ou conteúdo malicioso injetado em sites legítimos comprometidos (incluindo anúncios ou conteúdo enviado por usuários), induz a vítima a visitar a URL usando Internet Explorer. A descrição oficial também cita a possibilidade de embutir um controle ActiveX marcado como "safe for initialization" dentro de uma aplicação ou documento do Office que renderiza conteúdo via motor do IE — ampliando o vetor além do navegador puro.

O pré-requisito prático mais relevante é que a vítima use o Internet Explorer 11 (ou uma aplicação que hospeda seu motor de renderização) para abrir o conteúdo malicioso; não há necessidade de autenticação prévia no sistema nem de configuração não padrão além do uso do próprio IE. A interação do usuário exigida é mínima — visualizar a página é suficiente (UI:N no vetor CVSS confirma isso). Sozinha, a falha entrega execução de código no contexto do usuário logado, o que já é grave se o usuário tiver privilégios administrativos, mas o impacto documentado em campanhas reais foi maior.

A CVE está no catálogo KEV da CISA, confirmando exploração ativa. É publicamente conhecido — via pesquisa da comunidade de segurança que investigou essa família de vulnerabilidades no mesmo período — que essa falha em jscript9.dll foi observada sendo encadeada com uma vulnerabilidade de elevação de privilégio no kernel do Windows (win32k), permitindo escape do sandbox do IE e execução com privilégios de sistema, não apenas do usuário. Isso eleva o risco prático muito além do que o CVSS isolado (7.8) sugere, já que o encadeamento resulta em comprometimento total da máquina.

A correção definitiva é aplicar a atualização de segurança da Microsoft de agosto de 2020 (Patch Tuesday), disponível via Windows Update ou Microsoft Update Catalog para as versões suportadas do Windows que rodam Internet Explorer 11. A CISA, ao incluir a CVE no catálogo KEV, orienta apenas "aplicar atualizações conforme instruções do fornecedor" — não há detalhe adicional de mitigação alternativa publicado pela CISA nas fontes consultadas.

Como paliativo quando a atualização não pode ser aplicada imediatamente: reduzir a superfície de exposição do IE11 é a medida mais eficaz — restringir ou desativar o uso do Internet Explorer como navegador padrão, aplicar políticas de grupo que bloqueiem a execução de ActiveX e scripts em zonas não confiáveis, e migrar navegação de conteúdo web não confiável para outro motor de renderização. Executar o dia a dia com contas sem privilégios administrativos limita o impacto caso a exploração ocorra, mas não impede a execução de código no contexto do usuário — apenas reduz o que esse código consegue fazer.

Não existe mitigação de configuração dentro do próprio jscript9.dll (não há flag de registro documentada nas fontes consultadas que desative especificamente essa falha sem quebrar funcionalidade do motor de script). Confiar em antivírus ou EDR como controle primário não substitui o patch: a exploração ocorre em memória do processo do IE antes de qualquer payload em disco ser gravado, o que dificulta detecção puramente baseada em assinatura de arquivo.

Não há assinatura de rede ou de log padrão documentada nas fontes consultadas que identifique com confiabilidade uma tentativa de exploração dessa CVE especificamente — a corrupção ocorre em memória durante o parsing/execução de script pelo jscript9.dll, sem padrão de tráfego HTTP distintivo. Sinais indiretos que merecem investigação: processos filhos anômalos gerados a partir de iexplore.exe, crashes ou reinícios inesperados do processo do IE, e telemetria de EDR mostrando técnicas de escape de sandbox ou execução de shellcode a partir do espaço de endereço do IE.

Como a exploração documentada foi encadeada com uma falha de kernel, monitorar por elevação de privilégio inesperada originada a partir de processos do IE (win32k.sys, csrss.exe como alvo de manipulação) é um indicador mais concreto de exploração bem-sucedida da cadeia completa do que qualquer log específico dessa CVE isolada.