CVE-2023-42917

Corrupção de memória no motor WebKit que permite execução arbitrária de código ao processar conteúdo web malicioso, afetando iOS, iPadOS, macOS e Safari antes das versões corrigidas em novembro/dezembro de 2023. A Apple confirma que a falha foi explorada ativamente contra versões de iOS anteriores à 16.7.1, e ela está no catálogo KEV da CISA — não é uma CVE teórica, é peça de um exploit real usado em campanha direcionada.

A falha (CWE-362, race condition/uso inadequado de locking) está no WebKit, o motor de renderização usado pelo Safari e por qualquer app no ecossistema Apple que use WKWebView. A Apple descreve o problema como 'memory corruption... addressed with improved locking' — ou seja, uma condição de corrida em código que manipula recursos compartilhados sem sincronização correta, permitindo que dois caminhos de execução acessem/modifiquem a mesma estrutura de memória simultaneamente e corrompam seu estado. Isso é consistente com bugs de use-after-free ou double-free em engines JS/DOM, onde um objeto é liberado enquanto outra thread ainda o referencia.

A Apple não publicou detalhes de implementação além dessa frase genérica, e nenhuma das fontes catalogadas (advisories da Apple republicados no Fulldisclosure) traz análise técnica de terceiros sobre o mecanismo exato — não há PoC público nem writeup independente disponível nas fontes consultadas. O bug tem entrada correspondente no WebKit Bugzilla (#265067), mas o ticket não é público.

A CVE foi reportada por Clément Lecigne, do Google Threat Analysis Group (TAG), equipe que rotineiramente identifica exploits usados por operações de spyware comercial contra alvos específicos (jornalistas, dissidentes, diplomatas). A mesma pessoa reportou no mesmo lote a CVE-2023-42916 (leitura fora dos limites/out-of-bounds read no WebKit, divulgação de informação), corrigida no mesmo conjunto de patches — padrão típico de cadeia de exploração: um bug de leitura para vazar endereços de memória e derrotar ASLR, seguido do bug de corrupção de memória para conseguir execução de código.

Vetor de ataque é rede (AV:N): a vítima precisa apenas visitar uma página web ou renderizar conteúdo malicioso processado pelo WebKit — via Safari, um link aberto em qualquer app que use WebView, ou conteúdo embutido (iMessage, por exemplo, historicamente tem sido vetor para bugs de WebKit). O CVSS 3.1 marca UI:R (interação do usuário necessária) e PR:N (nenhum privilégio prévio), condições consistentes com ataque tipo watering-hole ou link malicioso enviado ao alvo — não exige autenticação, configuração não padrão nem acesso à rede local.

A Apple afirma estar ciente de exploração ativa contra iOS anterior à 16.7.1, o que motivou a entrada no catálogo KEV da CISA. Isso indica uso em campanha real, não apenas prova de conceito de pesquisador — o padrão de descoberta (TAG do Google, par com bug de info-leak) é típico de cadeias usadas por spyware comercial contra alvos de alto perfil, não de exploração massiva e indiscriminada. Não há indicação nas fontes de que um exploit público ou weaponizado esteja circulando amplamente após a correção.

O resultado final documentado pela Apple é execução arbitrária de código no contexto do processo WebKit — que em iOS/iPadOS roda em sandbox, então o impacto completo em um ataque real depende de encadeamento com um bug de sandbox escape/kernel (não coberto por esta CVE isoladamente).

Atualizar para iOS 17.1.2, iPadOS 17.1.2, macOS Sonoma 14.1.2, Safari 17.1.2 (para macOS Monterey e Ventura), tvOS 17.2 ou watchOS 10.2, conforme a plataforma. Não há patch para ramos anteriores ao 16.7.1 mencionados na correção original — dispositivos travados em versões antigas de iOS/iPadOS por incompatibilidade de hardware ficam expostos indefinidamente, já que a Apple não costuma retroportar correções de WebKit para essas linhas fora de ciclo de suporte.

Como paliativo real não existe flag de configuração que desative o componente vulnerável sem quebrar a navegação — WebKit é o motor obrigatório em iOS/iPadOS (nenhum outro engine é permitido pela política da plataforma) e o motor padrão do Safari em macOS. Reduzir exposição na prática significa restringir uso do Safari/WebView para navegação não confiável em dispositivos que não podem ser atualizados, ou isolar esses dispositivos de redes onde recebem links não verificados — não é mitigação técnica no sentido de patch virtual, é redução de superfície.

O que não funciona: extensões de bloqueio de anúncios ou scripts (uBlock etc.) não mitigam corrupção de memória no motor de renderização em si, porque o bug está na camada de parsing/execução do WebKit, não em JavaScript malicioso de terceiros que possa ser filtrado por regras de conteúdo.

Não há assinatura de rede ou padrão de tráfego conhecido e documentado para detectar tentativas de exploração — o ataque ocorre inteiramente client-side, dentro do processo de renderização do WebKit, ao carregar uma página. Não existem IOCs públicos, hashes de exploit ou domínios associados nas fontes disponíveis. Na prática, o único sinal indireto observável seria crash reports do processo WebKit/Safari (kernel panics, logs de crash em /Library/Logs/DiagnosticReports em macOS, ou diagnósticos coletados via MDM/Apple Configurator em frotas gerenciadas) anômalos e recorrentes antes da atualização — mas isso é evidência fraca e não substitui a atualização como controle primário.