CVE-2022-48503

Falha de corrupção de memória no JavaScriptCore, o motor JavaScript usado pelo WebKit em Safari, iOS, iPadOS, macOS, tvOS e watchOS. Processar conteúdo web malicioso pode levar à execução arbitrária de código dentro do processo que renderiza a página. Está no catálogo KEV da CISA, ou seja, há confirmação de exploração ativa antes da correção pública ampla — o que eleva a prioridade de patch mesmo com CVSS 8.8 e não 9+.

O problema está no JavaScriptCore, componente do WebKit responsável por compilar e executar JavaScript. A Apple descreve a causa como falha de verificação de limites ("improved bounds checks"), padrão típico de leitura ou escrita fora dos limites de um buffer (CWE-125/CWE-787) dentro do interpretador/JIT do motor JS. Esse tipo de bug em JSC costuma originar-se de confusão de tipos ou de cálculo incorreto de índice/tamanho ao manipular objetos JavaScript (arrays, TypedArrays, estruturas internas do engine), permitindo que um script controle dados fora da região de memória que deveria acessar.

O atacante controla o conteúdo JavaScript executado pela página — variáveis, tamanhos de array, tipos de objeto manipulados — o suficiente para forçar o motor a ler ou escrever fora do limite esperado durante a execução do script. Isso é a primitiva clássica usada para construir uma cadeia de exploração: primeiro corrupção de memória controlada, depois escalonamento para execução de código dentro do processo WebContent do WebKit (o processo sandboxed que renderiza páginas).

A referência ao WebKit Bugzilla 241931 aponta para o bug interno do projeto, mas não há detalhamento público do patch (diff) nas fontes analisadas. O CVE-ID foi adicionado aos advisories da Apple apenas em 21 de junho de 2023 — quase um ano depois de as correções (tvOS 15.6, watchOS 8.7, iOS/iPadOS 15.6, macOS Monterey 12.5, Safari 15.6, todos lançados em 20 de julho de 2022) já estarem disponíveis. Isso indica que a falha foi corrigida silenciosamente em 2022 e só depois formalmente atribuída a um CVE, padrão comum quando se descobre retroativamente que uma correção já lançada fechava uma falha explorada in-the-wild.

O vetor é web: a vítima precisa visitar uma página (ou abrir conteúdo) que contenha JavaScript malicioso capaz de acionar a condição de bounds-check no JSC. Não há necessidade de autenticação nem de configuração não padrão — qualquer navegador ou app que renderize conteúdo web via WebKit nas versões vulneráveis está exposto. O vetor CVSS confirma isso: AV:N (rede), AC:L (baixa complexidade), PR:N (sem privilégio), mas UI:R — exige interação do usuário, ou seja, ele precisa carregar a página ou o conteúdo malicioso.

A exploração de bugs de bounds-check em motores JS raramente é trivial isoladamente: normalmente servem como primitiva inicial de corrupção de memória dentro de uma cadeia maior, combinada com técnicas de bypass de mitigação (heap grooming, JIT spraying) para converter a escrita/leitura fora de limites em controle de fluxo de execução. O resultado final documentado pela Apple é execução arbitrária de código no contexto do processo que processa o conteúdo web — não há confirmação nas fontes analisadas de que essa CVE isolada inclua escape de sandbox para o sistema operacional.

A presença no catálogo KEV da CISA confirma exploração ativa observada por terceiros, mas as fontes consultadas não trazem detalhes de campanha, ator ou setor alvo. Dado o atraso entre o lançamento do patch (jul/2022) e a atribuição do CVE e entrada no KEV (jun/ago 2023), é provável que a exploração tenha sido identificada retroativamente durante investigação de outra cadeia de ataque, não no momento do lançamento.

Atualizar para as versões corrigidas é a única mitigação real: tvOS 15.6, watchOS 8.7, iOS 15.6, iPadOS 15.6, macOS Monterey 12.5, ou Safari 15.6 (para macOS Big Sur e Catalina, conforme HT213341). Não há flag de configuração, opção de desativar JavaScriptCore isoladamente de forma suportada, nem controle compensatório documentado pela Apple — o bug está no motor de execução de JS, então qualquer mitigação client-side real passa por atualizar o sistema/navegador.

Como paliativo temporário, em ambientes onde a atualização não é imediata, a única redução de superfície é restringir a navegação a conteúdo confiável ou desabilitar JavaScript no WebKit (o que quebra a maioria dos sites e não é viável na prática para uso geral). Isso não corrige a falha, apenas reduz a chance de exposição a página maliciosa.

Não existe mitigação via WAF ou controle de rede, porque a exploração ocorre no lado do cliente, dentro do motor de renderização — nenhum controle perimetral intercepta ou bloqueia o payload JavaScript malicioso de forma confiável, já que ele trafega como JavaScript legítimo dentro de HTTPS.

Não há assinatura de rede confiável para esta classe de vulnerabilidade: a exploração ocorre via JavaScript servido normalmente sobre HTTPS, indistinguível de tráfego web legítimo sem inspeção de conteúdo do script em si. Sinais possíveis incluem crashes ou comportamento anômalo (unexpected termination, uso incomum de memória) do processo WebContent do WebKit/Safari em endpoints, especialmente correlacionados com visitas a domínios recém-registrados ou vinculados a campanhas de spyware/watering-hole conhecidas — mas as fontes consultadas não fornecem IOCs, hashes ou domínios associados a esta CVE especificamente. Na ausência de indicadores públicos, a defesa prática é garantir que os endpoints estejam nas versões corrigidas.