CVE-2022-32893
Prioriza la corrección. Ella está bajo explotación confirmada por CISA.
Apply updates per vendor instructions.
Resumen
Falha de escrita fora dos limites (out-of-bounds write) no motor WebKit, que processa conteúdo web em Safari, WebKitGTK, WPE WebKit e em qualquer app que use o WebView do sistema em iOS, iPadOS e macOS. Basta a vítima visitar uma página maliciosa para o processo do WebKit corromper memória e potencialmente executar código arbitrário. A Apple confirmou exploração ativa antes da correção, e a falha está no catálogo KEV da CISA — não é um CVSS inflado sem uso real.
Detalle técnico
A vulnerabilidade é uma escrita fora dos limites de buffer (CWE-787) dentro do WebKit, corrigida pela Apple com 'improved bounds checking'. O fornecedor não detalhou qual componente interno do motor de renderização ou JavaScript engine está envolvido — como é padrão nos advisories da Apple, a descrição pública se limita ao tipo de falha e ao efeito. O rastreamento é feito no WebKit Bugzilla como bug 243557, aberto em 04/08/2022, com um patch (incluindo testes unitários) já vinculado poucos minutos depois no GitHub, sugerindo que a correção técnica ficou publicamente rastreável antes de qualquer aviso formal.
O atacante controla o conteúdo web processado pelo motor — HTML, CSS, JavaScript ou outro conteúdo interpretável pelo WebKit — entregue via página, anúncio, iframe ou qualquer superfície que renderize conteúdo remoto. A escrita fora dos limites ocorre durante o parsing/processamento desse conteúdo malicioso, corrompendo memória do processo do WebKit e abrindo caminho para execução de código dentro do contexto do processo de renderização (sandboxed no caso do WebContent process em iOS/macOS modernos).
A mesma correção alcançou WebKitGTK e WPE WebKit (usados em distribuições Linux) nas versões anteriores à 2.36.7, conforme WSA-2022-0008. Isso indica que a falha reside no núcleo compartilhado do WebKit, não em código exclusivo da integração da Apple.
Cómo se explota
O vetor é web: a vítima precisa carregar conteúdo malicioso em um app que use o motor WebKit (Safari, WebViews de apps de terceiros, WebKitGTK/WPE em Linux). CVSS 3.1 classifica UI:R (interação do usuário necessária) e AV:N/AC:L — sem necessidade de autenticação, mas dependente de o usuário abrir ou navegar até o conteúdo malicioso. A execução de código obtida fica, em princípio, confinada ao sandbox do processo que renderiza o conteúdo web.
A Apple publicou correções para CVE-2022-32893 (WebKit, RCE) e CVE-2022-32894 (kernel, out-of-bounds write, escalonamento a privilégios de kernel) no mesmo dia, ambas marcadas como 'may have been actively exploited'. Essa coincidência — e o fato de a nota de segurança do iOS 12.5.6 mencionar explicitamente que 'iOS 12 is not impacted by CVE-2022-32894' — é consistente com uma cadeia de exploração típica de spyware comercial: comprometer o processo de renderização via WebKit e depois escapar do sandbox via a falha de kernel. A Apple não confirmou publicamente o encadeamento; é inferência baseada no padrão de divulgação, não fato documentado pelo fornecedor.
A thread no oss-security aponta que o bug ficou publicamente rastreável no WebKit Bugzilla desde 04/08/2022, com patch visível no GitHub pouco depois, mas o WSA formal do WebKitGTK só saiu em 25/08/2022 — quase três semanas de exposição para quem acompanha apenas os canais oficiais dos distribuidores Linux, mesmo com o código de correção já público.
Versiones
Cómo protegerse
Atualizar é a única mitigação real: iOS/iPadOS para 15.6.1 (dispositivos legados suportados por iOS 12 recebem 12.5.6), macOS Monterey para 12.5.1, Safari (em macOS Big Sur/Catalina) para 15.6.1, e WebKitGTK/WPE WebKit para 2.36.7 ou superior em sistemas Linux. Distribuições que empacotam WebKitGTK/WPE (Debian, Fedora, Gentoo, conforme os avisos catalogados) precisam do pacote atualizado especificamente — não basta atualizar o sistema operacional em geral se o pacote WebKit não subir de versão.
Não há paliativo funcional equivalente a patch: como é falha de memória no parsing de conteúdo web, desativar JavaScript reduz superfície de ataque mas não elimina o risco (o bug pode estar em parsing de HTML/CSS, não necessariamente em JS) e quebra a maior parte dos sites. Em ambientes corporativos sem capacidade de atualizar de imediato, a única redução real de risco é restringir o acesso à web em dispositivos afetados (proxy com allowlist, bloqueio de navegação livre) — controle compensatório caro e raramente viável para usuários finais.
Mito comum: acreditar que app não-Safari está seguro. Qualquer app que embuta WKWebView/UIWebView ou WebKitGTK herda a vulnerabilidade até a atualização do framework do sistema — não é suficiente evitar o navegador Safari.
Cómo detectar
Não há assinatura de rede confiável para essa classe de falha — é corrupção de memória no parsing de conteúdo web, sem payload de rede padronizado publicamente conhecido. Indicadores possíveis, mas não conclusivos, incluem crashes anômalos e repetidos do processo WebContent/Safari (ou do processo webkitgtk/WPEWebKit em Linux) registrados nos logs do sistema, especialmente em dispositivos que visitaram sites incomuns antes da falha. A ausência de PoC público e de IOCs divulgados pela Apple ou pela comunidade WebKit significa que detectar exploração retroativa depende de forense de dispositivo (crash logs, análise de memória), não de assinatura de tráfego ou WAF.