CVE-2022-26485

Use-after-free no processador XSLT do Firefox/Gecko, explorável para execução de código dentro do processo de conteúdo do navegador. A falha foi usada em ataques reais antes da correção — está no catálogo KEV da CISA e o próprio advisory da Mozilla confirma exploração in the wild — o que a torna mais urgente do que o CVSS 8.8 já sugere, já que exploração confirmada muda a prioridade de patch.

A vulnerabilidade (CWE-416, use-after-free) está em txMozillaXSLTProcessor.cpp, na função txVariable::Convert (linha 1361 no código afetado). Quando o XSLTProcessor converte o valor de um parâmetro XSLT que é um objeto JS, ele chama JS::ToString sobre esse objeto para obter uma string. Se o objeto tiver um método customizado Symbol.toPrimitive (hook controlado por script do atacante), essa chamada executa JavaScript arbitrário no meio da conversão.

O problema é que esse callback JS pode, dentro de si mesmo, chamar XSLTProcessor.removeParameter() para remover o próprio parâmetro que está sendo convertido. Isso libera o objeto txVariable subjacente na memória nativa. Quando o fluxo de execução em C++ retorna do callback e continua a usar o ponteiro para esse txVariable (via txVariable::getValue, txExecutionState::getVariable, VariableRefExpr::evaluate, até txXSLTProcessor::execute), ele opera sobre memória já liberada — o clássico use-after-free.

O atacante controla o objeto passado como valor do parâmetro (via setParameter) e, por extensão, controla exatamente quando o toPrimitive dispara e quando removeParameter é chamado — ou seja, controla o timing da liberação de memória em relação ao uso subsequente, o que é o que torna o bug explorável de forma confiável (heap grooming/reuso de memória liberada com dados controlados).

O fluxo de exploração passa por APIs padrão do DOM: DOMParser, XSLTProcessor.importStylesheet, setParameter e transformToDocument — nenhuma API privada ou de depuração, apenas uso incomum e malicioso de funcionalidade XSLT legítima do navegador.

O vetor é puramente client-side: a vítima precisa visitar uma página web (ou abrir conteúdo HTML/e-mail renderizado, no caso do Thunderbird) que contenha um script malicioso usando a API XSLTProcessor. Não há necessidade de autenticação, privilégio elevado ou configuração não padrão do navegador — a API XSLT está disponível por padrão em qualquer página web. O CVSS reflete isso: AV:N, AC:L, PR:N, mas exige UI:R (interação do usuário, no caso, apenas navegar até a página).

A exploração depende de JavaScript definindo um objeto com Symbol.toPrimitive customizado, passado como parâmetro XSLT via setParameter, e então chamando transformToDocument. Dentro do hook toPrimitive, o script chama removeParameter para liberar a memória usada pelo parâmetro enquanto ele ainda está em uso pelo motor XSLT nativo. A partir daí, o exploit precisa realocar a memória liberada com dados controlados (heap grooming) para converter o UAF em corrupção de memória controlada e, potencialmente, execução de código dentro do processo de conteúdo do navegador.

O relatório da Mozilla e o bug no Bugzilla confirmam que houve ataques reais explorando essa falha antes da correção, atribuídos por pesquisadores da 360 ATA (Wang Gang, Liu Jialei, Du Sihang, Huang Yi, Yang Kang), que reportaram a exploração in the wild. A CISA incluiu a CVE no catálogo KEV, confirmando exploração ativa documentada. Não há indicação pública de qual campanha ou ator usou a falha, nem de encadeamento confirmado com outra CVE para escape de sandbox no advisory lido (a CVE-2022-26486, de WebGPU, aparece no mesmo boletim e também tem relatos de exploração, mas trata-se de uma falha separada).

A correção definitiva é atualizar para as versões corrigidas: Firefox 97.0.2, Firefox ESR 91.6.1, Firefox for Android 97.3.0, Focus 97.3.0 e Thunderbird 91.6.2. Não há flag de configuração ou preferência conhecida publicada pela Mozilla que desative especificamente o processamento de parâmetros XSLT sem quebrar funcionalidade — a mitigação real é a atualização do binário do navegador/cliente de e-mail.

Como paliativo em ambientes que não conseguem atualizar imediatamente, a única redução de superfície plausível é impedir a execução de JavaScript não confiável (políticas de navegação restritiva, isolamento de sites não confiáveis, ou uso de perfis/containers separados), já que o vetor depende inteiramente de script controlado pelo atacante manipulando a API XSLTProcessor. Isso reduz risco, não elimina — não é substituto de patch.

Não é uma mitigação eficaz simplesmente bloquear extensões de arquivo .xsl ou tentar filtrar conteúdo XSLT por assinatura no WAF/proxy: o vetor é JavaScript no navegador manipulando a API DOM diretamente, não um arquivo XSLT externo carregado por URL — não há payload de rede fixo para assinar de forma confiável.

Não há assinatura de rede confiável: a exploração ocorre inteiramente no lado do cliente, dentro do processo de conteúdo do navegador, via JavaScript e APIs DOM padrão (XSLTProcessor, DOMParser). Não existe padrão de tráfego HTTP distintivo a procurar em proxies ou IDS.

Em nível de host/EDR, o sinal possível é crash ou comportamento anômalo do processo de conteúdo do Firefox/Thunderbird (queda inesperada, uso de memória corrompida detectado por sanitizers em ambientes de debug/telemetria), ou telemetria de exceções internas do motor XSLT. Para análise forense de página suspeita, procurar por scripts que definem Symbol.toPrimitive customizado em conjunto com chamadas a XSLTProcessor.setParameter/removeParameter/transformToDocument é o indicador mais próximo de um artefato de exploração, mas não existe assinatura oficial publicada pela Mozilla ou pela CISA para essa CVE.