CVE-2017-0037

Falha de type confusion (CWE-704) na função Layout::MultiColumnBoxBuilder::HandleColumnBreakOnColumnSpanningElement do mshtml.dll, afetando Internet Explorer 10, 11 e Microsoft Edge (EdgeHTML) no Windows. Descoberta pelo Google Project Zero, com PoC público e exploração confirmada — está no catálogo KEV da CISA desde 2022. O CVSS de 8.1 é alto, mas o AC:H reflete a realidade: chegar de crash a execução de código confiável exige uma cadeia de infoleak + heap grooming, não é trivial de disparar em RCE estável.

O bug vive no motor de layout de páginas do mshtml.dll, especificamente no tratamento de quebra de coluna (column-span) em elementos de tabela dentro de um layout CSS multi-coluna. Um estilo combinando column-count, column-span:all e columns em conjunto com um elemento TH manipulado via JavaScript (alteração dinâmica de propriedades como align, disparada em loop com setInterval) confunde o motor sobre o tipo real do objeto sendo lido: em vez de apontar para o objeto de layout esperado, o código passa a interpretar um array de inteiros de 32 bits — que armazena offsets de colunas da tabela e é populado com valores que o atacante controla via CSS/JS — como se fosse um ponteiro para outro tipo de objeto C++.

A análise pública do Project Zero (issue 1011) mostra o crash ocorrendo ao ler um endereço inválido dentro dessa função, alcançada pelo pipeline normal de repintura/layout (CView::EnsureView → LayoutBuilder → PageCollection → MultiColumnBoxBuilder). Como o array de offsets é atacante-controlado, o valor interpretado como ponteiro (e posteriormente usado para uma chamada indireta via ponteiro de função, visível no disassembly como 'call rdi' após dereferências encadeadas) pode ser manipulado, abrindo caminho para desvio de fluxo de execução.

O CWE-704 (Incorrect Type Conversion or Cast) descreve bem a classe: o motor assume um layout de memória de um tipo específico (Layout::PatchableArrayData) para uma estrutura que, no PoC, foi substituída por um array de valores numéricos de tabela — confusão de tipo clássica de motor de renderização legado escrito em C++ sem checagem de tipo em runtime nesse ponto do código.

O vetor é uma página HTML servida remotamente (ou conteúdo HTML embutido, por exemplo em documentos que renderizam via mshtml.dll) contendo CSS malformado (column-span/column-count/columns) e JavaScript que manipula um elemento TH em loop. Não há exigência de autenticação nem de privilégio (PR:N) e a interação do usuário se resume a abrir/visualizar a página (UI:N) — o gatilho dispara sozinho via onload/setInterval. O que a manchete CVSS 8.1 não deixa claro é o AC:H: para ir de um crash controlado a execução de código arbitrário, os exploits públicos (EDB-42354, EDB-43125, ambos ligados ao boletim MS17-007) mostram que é necessário primeiro vazar um endereço de memória (infoleak via manipulação de textarea/iframe/elementos de áudio, que reaproveita alocações internas do motor) para calcular o base address de um módulo (ntdll, propsys), e depois fazer heap grooming/spray massivo (via centenas de elementos com atributo title longo) para posicionar uma ROP chain e o shellcode em endereço previsível, contornando DEP e ASLR.

Sem essa cadeia completa (infoleak + spray + ROP), o efeito prático mais comum é apenas negação de serviço — o navegador ou processo de renderização trava. Isso é relevante para triagem: exploits observados publicamente miram Windows 7/x86 e builds específicos de IE11 de 2016-2017; a portabilidade para outras versões de Windows/IE depende de offsets de ROP gadgets que variam por build.

A CISA confirma exploração no mundo real (adição ao KEV em 28/03/2022, com prazo de correção 18/04/2022), embora a adição tardia — cinco anos após a publicação da CVE — provavelmente reflete o uso contínuo do exploit em campanhas contra sistemas Windows não atualizados, não uma nova onda de ataques em 2022.

A correção oficial veio na atualização de segurança de fevereiro de 2017, associada ao boletim MS17-007, que cobre tanto IE10/11 quanto Edge (EdgeHTML). As fontes consultadas não trazem o número de KB específico nem builds exatos por SKU do Windows — para confirmar que um sistema está corrigido, verificar se todas as atualizações cumulativas do Windows a partir de fevereiro de 2017 foram aplicadas, e não confiar em versão de IE/Edge isolada como prova de patch.

Para ambientes que ainda rodam Windows fora de suporte oficial e não podem aplicar a atualização, a única mitigação de terceiros catalogada é o micropatch da 0patch (referenciado no catálogo, sem detalhamento técnico verificado aqui) — trata-se de correção não-oficial, fora do ciclo de suporte da Microsoft, e deve ser tratada como paliativo, não substituto do patch oficial. Como controle compensatório técnico: restringir o uso de mshtml.dll/IE legado a sites de confiança via zonas de segurança, forçar Enhanced Protected Mode, e migrar navegação geral para um motor diferente do EdgeHTML/Trident.

O que não funciona como mitigação: assinatura de antivírus baseada em padrão estático do PoC — o CSS e o JavaScript usados no gatilho são triviais de reescrever sem alterar o comportamento, tornando detecção por assinatura de conteúdo pouco confiável.

Não há assinatura de rede confiável: o vetor é HTML/CSS/JavaScript arbitrário e os PoCs públicos são triviais de reescrever sem alterar o comportamento de fundo. Sinais comportamentais mais úteis em EDR/host: crash de iexplore.exe, MicrosoftEdgeCP.exe ou do módulo mshtml.dll com acesso a endereço inválido; criação de processos filho inesperados (ex. cmd.exe, calc.exe — usado nos PoCs de prova de conceito com msfvenom) a partir do processo do navegador; e padrões de heap spray incomuns, como criação massiva de elementos DOM com atributos title muito longos, ou criação dinâmica repetida de / dentro de um mesmo carregamento de página.