CVE-2017-0059

Falha de use-after-free no MSHTML (motor de renderização do Internet Explorer 9 a 11) que permite a um site malicioso ler memória do processo do navegador. Isoladamente é só um vazamento de informação (CWE-200, impacto baixo de confidencialidade), mas pesquisadores demonstraram que ela serve como primitiva de leak de endereço para quebrar ASLR e encadear com outra falha (CVE-2017-0037) até execução de código. Está no catálogo KEV da CISA por exploração confirmada e tem EPSS alto (~62%), o que justifica prioridade mesmo com CVSS 4.3.

O bug está no tratamento do elemento pelo MSHTML. A cadeia de PoC publicada (originada de um relatório do Google Project Zero, bug id 1076) cria um , insere um dentro dele e, no evento onreadystatechange do iframe, chama form.reset(). O reset dispara MSHTML!CFormElement::DoReset -> CRichtext::DoReset -> CRichtext::SetValueHelperInternal -> CElement::InjectInternal, que libera (free) a alocação de texto associada ao valor antigo do textarea. Em seguida, o script seta textarea.defaultValue novamente, o que reutiliza (use) a referência já liberada antes de ela ser reatribuída — um use-after-free clássico.

A causa raiz, documentada no crash dump do PoC, é que as alocações de texto de elementos de formulário não são protegidas pelo mecanismo MemGC do IE (que mitiga UAF em outros objetos DOM) porque ficam no heap de processo comum. Isso torna esse UAF específico explorável de forma confiável: o atacante controla o timing do free (via form.reset()) e o conteúdo realocado na posição liberada (via spray de heap com outros elementos, como ou nos exploits mais completos), conseguindo ler bytes de memória do processo que caem naquele slot.

O CVE-2017-0059 cobre especificamente esse vazamento de leitura; a Microsoft tratou isso como vulnerabilidade distinta de CVE-2017-0008 e CVE-2017-0009, que são outras falhas de disclosure no mesmo pacote de correções de março de 2017.

O vetor é totalmente client-side: o atacante hospeda uma página com o JavaScript malicioso e depende de a vítima abri-la no Internet Explorer (UI:R no vetor CVSS) — não há autenticação, nem configuração não padrão exigida, só uso do IE vulnerável. AC é baixo porque o exploit não depende de condições de corrida sofisticadas nem de acesso privilegiado.

Na prática, o resultado direto da CVE-2017-0059 é o atacante conseguir ler conteúdo de memória alocada no heap do processo do IE — usado nos PoCs para recuperar o endereço base de módulos como ntdll.dll ou propsys.dll, quebrando ASLR. Os exploits públicos mais avançados (EDB 42354 e 43125) não usam a falha isoladamente: eles a combinam com CVE-2017-0037 (confusão de tipo em mshtml.dll) para montar uma cadeia ROP e conseguir execução de código arbitrário, contornando DEP via VirtualProtect/VirtualAlloc. Isso é importante: a CVE-2017-0059 por si só concede apenas leitura de memória, não RCE — os títulos "Remote Code Execution" nos exploits referem-se à cadeia completa, não a esta CVE isolada.

A presença no catálogo KEV da CISA (adicionada em 28/03/2022) confirma exploração no mundo real, embora sem detalhamento de campanha específica. A combinação de PoC público desde 2017 e uso confirmado depois torna plausível reaproveitamento em kits de exploração para Windows/IE legado.

A correção veio pela atualização de segurança do Internet Explorer de março de 2017. Os PoCs publicados referenciam o boletim MS17-006 como origem da correção; a página de referência oficial é o Security Update Guide da Microsoft (MSRC), que deve ser consultado para a KB exata aplicável a cada versão de Windows/IE, pois essa informação não pôde ser confirmada diretamente aqui — não assuma uma KB específica sem checar o advisory.

O paliativo real quando a atualização não pode ser aplicada é reduzir a superfície de ataque do MSHTML: desabilitar o Internet Explorer como navegador ativo (usando Modo Empresarial/Enhanced Security Configuration), restringir a execução de JavaScript em zonas não confiáveis, ou isolar o IE em uma zona com Enhanced Protected Mode. Como a falha está em mshtml.dll, qualquer aplicação que renderize HTML via esse componente (não só o navegador IE, mas WebBrowser Control embutido em outros programas) também é afetada e precisa da mesma atualização.

O que não funciona como mitigação: bloquear apenas o EDB-ID específico do exploit ou assinatura de payload não cobre variações do vetor, já que o mecanismo (textarea + iframe + form.reset) é trivial de reescrever. Migrar para um navegador atualizado que não use MSHTML elimina o problema por completo e é a única mitigação estrutural, mas isso é decisão de arquitetura, não uma configuração pontual.

Não há assinatura de rede confiável: a exploração ocorre inteiramente no lado do cliente, via JavaScript renderizado localmente pelo mshtml.dll, sem payload de rede distintivo além do HTML/JS malicioso em si — que pode ser trivialmente ofuscado. Em nível de host, sinais possíveis incluem crashes do iexplore.exe/mshtml.dll com stack trace passando por CElement::InjectInternal/CRichtext::SetValueHelperInternal (visível em dumps de Page Heap ou em telemetria de EDR), e o padrão de código-fonte contendo textarea + iframe + form.reset() + defaultValue em sequência, que pode ser usado como heurística para inspeção de conteúdo web armazenado/capturado, mas não como detecção determinística.