CVE-2019-1367

Vulnerabilidade de corrupção de memória no motor de scripts do Internet Explorer (9, 10 e 11) que permite execução remota de código no contexto do usuário atual, geralmente via página web maliciosa. Foi corrigida por atualização fora do ciclo normal do Patch Tuesday, o que por si só indica exploração ativa antes do patch — está confirmada no catálogo KEV da CISA como explorada no mundo real.

A falha reside na forma como o scripting engine do Internet Explorer manipula objetos em memória, resultando em corrupção de memória (CISA classifica como CWE-787, escrita fora dos limites). O vetor CVSS informado (AC:H, UI:R) indica que a exploração não é trivial: exige que a vítima interaja com conteúdo controlado pelo atacante (abrir uma página ou documento que carregue o engine de scripts do IE) e que o atacante consiga condições específicas de memória/heap para transformar a corrupção em execução de código confiável — típico de cadeias que envolvem manipulação de layout de heap antes de acionar a condição de erro.

O advisory oficial da Microsoft não detalha a rota exata do código (qual componente do jscript/jscript9 ou qual objeto DOM/script está envolvido), e não localizamos análise técnica detalhada nas fontes disponíveis para esta página. O que se sabe com certeza, pela descrição oficial e pelo CISA, é que o problema está no scripting engine usado pelo IE ao processar objetos, e que o resultado de exploração bem-sucedida é execução de código no contexto do usuário logado — não em nível de sistema, salvo encadeamento com uma segunda falha de elevação de privilégio.

O CVE é listado como distinto do CVE-2019-1221, outra falha de memória do scripting engine corrigida no mesmo período, o que sugere que a Microsoft tratou múltiplas variantes/relatos separados envolvendo o mesmo componente.

O vetor de ataque mais provável, dado o produto afetado, é o usuário abrir uma página web maliciosa (ou conteúdo HTML incorporado, como em um documento Office que renderize via engine do IE) no Internet Explorer. Não há exigência de autenticação nem de configuração não padrão — o pré-requisito real é a vítima usar o IE (ou um componente que embuta o mecanismo de renderização/scripting do IE) e interagir com o conteúdo malicioso, conforme indicado por UI:R no vetor CVSS.

A complexidade de ataque é classificada como alta (AC:H), o que normalmente reflete a necessidade de manipular o estado da memória (heap grooming) para tornar a corrupção explorável de forma confiável — um passo técnico não trivial, mas dominado por atores capazes de zero-day, o que é consistente com o fato de a CISA ter adicionado o CVE ao catálogo KEV por exploração confirmada in the wild antes ou próximo da correção.

O resultado final da exploração bem-sucedida é execução de código arbitrário no contexto de privilégio do usuário que executa o IE — não necessariamente administrador. Em campanhas reais, esse tipo de falha costuma ser usado como estágio inicial de comprometimento (drive-by download), muitas vezes combinado com uma vulnerabilidade de elevação de privilégio local para obter controle total do sistema.

A mitigação definitiva é aplicar a atualização de segurança da Microsoft para o Internet Explorer correspondente à versão do Windows em uso — a Microsoft publicou correção fora do ciclo normal de Patch Tuesday em 23/09/2019 (a data de publicação do CVE coincide com o lançamento do patch, fora do calendário mensal padrão, o que reforça o caráter emergencial da correção). Não temos, nas fontes verificadas, o número exato de cada KB por versão de Windows/IE — consulte o advisory oficial da Microsoft (MSRC) para os pacotes específicos de cada sistema (IE 9, 10, 11 em Windows Server 2012, Windows 10 1903 em x86/x64/ARM64, etc.).

Se a atualização não puder ser aplicada imediatamente, o controle compensatório mais eficaz é reduzir a superfície de uso do Internet Explorer como navegador de renderização ativa: restringir ou desabilitar o motor de scripts (JScript) em zonas de segurança não confiáveis, aplicar políticas de Enhanced Security Configuration, ou migrar o tráfego de navegação para outro motor de renderização que não dependa do componente vulnerável. Esses paliativos reduzem mas não eliminam o risco, e têm custo funcional (páginas que dependem de JScript legado podem quebrar).

Não funciona como mitigação apenas desabilitar o Internet Explorer como aplicativo padrão sem tratar componentes que ainda o invocam internamente (por exemplo, controles ActiveX ou visualizadores que embutem o mote de renderização do IE em outras aplicações) — o vetor de ataque pode persistir mesmo que o usuário não abra o IE diretamente.

Não há assinatura de rede ou de log padronizada e confiável descrita nas fontes disponíveis para identificar tentativas de exploração desta falha especificamente — corrupção de memória em motor de scripts tende a se manifestar como crash do processo do Internet Explorer (iexplore.exe) ou de processos que hospedam o engine, o que pode aparecer em logs de Watson/Crash Reporting do Windows ou em EDR como falha de acesso à memória seguida de execução anômala de processo filho. Ambientes que ainda operam IE devem monitorar crashes recorrentes do navegador associados a acesso a páginas externas e checar telemetria de EDR por padrões de shellcode/heap spraying originados do processo do IE, mas isso é indício geral de exploração de memória, não uma assinatura específica desta CVE.