CVE-2022-26486

Use-after-free na implementação IPC do WebGPU no processo de conteúdo/GPU do Firefox, permitindo escape do sandbox e execução de código no processo GPU (privilegiado). A falha foi reportada por pesquisadores da 360 ATA com evidência de exploração ativa antes da correção, e foi corrigida junto com outra UAF (CVE-2022-26485, em XSLT) usada como par de exploração em cadeia. O detalhe crítico que a CVSS de 9.6 não capta: WebGPU vem desabilitado por padrão em todas as versões do Firefox, e nem os engenheiros da Mozilla conseguiram inicialmente explicar como o ator IPC do WebGPU era alcançado com o recurso desligado.

A falha (CWE-416) está no gerenciador de status do WebGPU dentro do framework IPC que conecta o processo de conteúdo (renderer) ao processo GPU do Firefox. O código de referência publicado no bug mostra a sequência: o atacante invoca mozilla::webgpu::Instance::Create e, em seguida, mozilla::webgpu::PWebGPUChild::SendShutdown — uma mensagem IPC inesperada nesse ponto do ciclo de vida deixa o objeto WebGPU em um estado inconsistente. WebGPUParent::RecvShutdown() limpa mCanvasMap, executa wgpu_server_poll_all_devices e wgpu_server_delete sobre mContext, mas não zera o ponteiro mContext depois — deixando uma referência pendente que pode ser reutilizada.

Com o objeto em estado inválido e um layout de heap manipulado ("heap grooming"), uma segunda mensagem IPC — SendShaderModuleDestroy, segundo o relato do descobridor — aciona a leitura/escrita sobre a memória já liberada, dando ao atacante controle suficiente para execução de código dentro do processo GPU.

Um ponto não resolvido publicamente pelos próprios engenheiros da Mozilla nos comentários do bug: uma verificação que bloqueia a alocação do ator WebGPUParent quando o pref do WebGPU está desabilitado (o padrão em todas as versões) já existia desde o Firefox 94 e ainda estava presente no Firefox 97.0.1. Como a mensagem SendShutdown chegou ao parent mesmo com essa guarda em vigor não foi esclarecido no bug público — a correção final incluiu um patch separado ("Better check the webgpu pref") para reforçar essa verificação, sugerindo que havia uma via de bypass do gate de pref.

A Mozilla já tinha corrigido uma variante relacionada da UAF no canal beta (bug 1746538) por acidente — um fix que resolveu o bug sem que a causa raiz de segurança tivesse sido identificada como tal — mas essa correção não foi sincronizada para o canal stable (97.0.1), que permaneceu vulnerável e foi o alvo da exploração reportada.

O vetor é uma mensagem IPC do processo de conteúdo/renderer para o processo GPU, abusando da API WebGPU. Como o WebGPU vem desabilitado por padrão, a exploração direta a partir de uma página web comum não é trivial — o atacante precisa primeiro obter execução de código no processo de conteúdo (renderer) por outro meio, e o advisory da Mozilla lista essa vulnerabilidade junto com CVE-2022-26485 (UAF em XSLT), atribuída ao mesmo grupo de pesquisadores (360 ATA) e também com relatos de exploração em estado selvagem — um padrão consistente com uma cadeia de exploração de dois estágios: comprometer o renderer primeiro, depois usar o UAF do WebGPU para escapar do sandbox e comprometer o processo GPU, que tem privilégios mais altos (especialmente relevante no Windows, onde o processo GPU tem acesso mais amplo ao sistema).

A exploração exige controle sobre o timing e a sequência de mensagens IPC enviadas ao processo GPU, além de manipulação de heap para tornar a UAF confiável — não é um bug trivialmente determinístico, exige heap grooming cuidadoso, conforme indicado pelo próprio relato técnico do descobridor.

A CISA incluiu a falha no catálogo KEV com confirmação de exploração ativa (data de adição 2022-03-07, praticamente coincidindo com o lançamento da correção em 2022-03-05), o que indica que o uso em ataques reais precedeu o patch — provavelmente em campanha direcionada, dado o nível de sofisticação necessário (cadeia de duas UAFs, bypass de guarda de pref, heap grooming), não exploração massiva oportunista.

A correção definitiva é atualizar para Firefox 97.0.2 ou posterior, Firefox ESR 91.6.1 ou posterior, Firefox para Android 97.3.0 ou posterior, Thunderbird 91.6.2 ou posterior, ou Focus 97.3.0 ou posterior. Não há paliativo de configuração documentado publicamente pela Mozilla para quem não pode atualizar — o simples fato de o WebGPU estar desabilitado por padrão não é garantia de proteção total, já que o próprio caso demonstrou exploração contra builds em que a guarda de pref deveria bloquear o vetor.

Como controle compensatório, ambientes que não podem atualizar imediatamente devem confirmar explicitamente que o pref dom.webgpu.enabled (ou equivalente) está desabilitado e bloqueado por política, mas isso não deve ser tratado como mitigação equivalente ao patch — o mecanismo exato de bypass da guarda de pref não foi detalhado publicamente, então não há garantia de que desabilitar o recurso via política elimine o risco por completo enquanto a correção de reforço da verificação ("Better check the webgpu pref") não estiver aplicada.

Isolamento de processo (sandboxing) do sistema operacional e atualização do navegador continuam sendo os controles reais; não há mitigação via WAF ou controle de rede aplicável, pois a exploração ocorre inteiramente dentro do próprio navegador via IPC interno.

Não há assinatura pública de detecção de rede ou de log confiável para esta falha — a exploração ocorre via mensagens IPC internas entre processos do navegador (conteúdo → GPU), sem artefato de rede característico. Indicadores indiretos possíveis incluem crashes ou travamentos anômalos do processo GPU do Firefox (visíveis em relatórios de crash internos, about:crashes) precedendo comportamento inesperado do navegador, mas isso não distingue exploração maliciosa de bugs legítimos sem análise forense da memória do processo.