The Deathray: Uma maneira simples para um site não confiável congelar um Mac

Artigo original ↗ Discussão no Hacker News ↗

Um exploit de WebGPU recentemente destacado pode congelar de forma confiável máquinas macOS — e alguns dispositivos Android — simplesmente ao visitar uma página especialmente criada, em alguns casos forçando reinicializações bruscas e travamentos repetidos quando os navegadores restauram abas automaticamente. Comentadores debatem se esse tipo de negação de serviço deve ser tratado como uma vulnerabilidade de segurança séria, apontando o potencial para golpes no estilo ransomware, perda de dados e danos a usuários não técnicos que não conseguem identificar facilmente a causa. O incidente também alimenta críticas mais amplas à exposição de cada vez mais recursos de GPU e hardware à web, contrapondo desempenho e apps web ricos a uma superfície de ataque maior e à instabilidade do sistema.

Comportamento observado e gravidade

  • Muitos usuários do macOS relatam travamentos completos do sistema: o cursor pode se mover, mas a interface, o Force Quit e a entrada de dados ficam sem პასუხa; muitas vezes é necessário desligar forçadamente.
  • Em alguns Macs, isso só derruba o Safari ou a aba; fechar o navegador imediatamente restaura a operação normal.
  • Alguns relatos extremos: falhas repetidas no login devido a abas restauradas automaticamente; um usuário inicialmente não conseguiu nem inicializar em modo de segurança e precisou de uma atualização/reinstalação antes da recuperação.
  • O comportamento fora do macOS é misto:
    • Alguns navegadores no Windows apenas congelam a aba ou todas as abas por um instante e então encerram a página ofensiva.
    • Alguns dispositivos Android (por exemplo, Pixel, Samsung) supostamente congelam totalmente; outros, com navegadores diferentes ou versões endurecidas do sistema, veem apenas pequenas travadas ou nada.
    • Casos no Linux/Firefox variam de um navegador que caiu a nenhum impacto visível.
  • Relata-se que o iOS não é afetado; o macOS 27 RC ainda está impactado.

Debate sobre segurança e modelo de ameaça (DoS)

  • Há forte preocupação de que um congelamento confiável disparado pelo navegador seja uma negação de serviço significativa e, portanto, um problema de segurança.
  • Casos de abuso sugeridos: scareware (“seu computador travou por causa de um vírus”), extorsão no estilo “vamos continuar travando você, a menos que…”, coerção por ad-tech (“desative o adblock ou vamos derrubar sua máquina”), golpes de falso antivírus mais convincentes porque a máquina realmente travou.
  • Outros argumentam que isso é “só disponibilidade”, sem roubo de dados nem escalonamento de privilégios, então teria prioridade menor.
  • Há discordância sobre o comportamento do usuário:
    • Um lado afirma que isso é “autocorrigível” porque os usuários evitariam sites que travam seus computadores.
    • Outros contra-argumentam que usuários comuns não ligarão travamento ↔ site, ficarão presos em loops de restauração automática ou acabarão ligando para golpistas de “suporte técnico”.

Responsabilidade: sistema operacional vs navegador vs WebGPU

  • Alguns enquadram isso principalmente como um bug do macOS: outros sistemas operacionais têm watchdogs de GPU que reiniciam cargas de trabalho problemáticas; o macOS ainda permite que travamentos da GPU derrubem todo o sistema/WindowServer.
  • Outros veem isso como algo inerente ao WebGPU/WebGL: a web nunca deveria poder travar uma máquina, independentemente do comportamento do sistema operacional.
  • O fio observa que a Apple encerrou problemas semelhantes de WebGPU como “não relevantes para segurança”.

Visões mais amplas sobre WebGPU e a web como plataforma de aplicativos

  • Corrente cética:
    • Preocupação com uma superfície de ataque de hardware em constante expansão nos navegadores (WebGPU, WebUSB, etc.).
    • Argumento de que navegadores foram feitos para documentos, não como uma camada completa de aplicativo/runtime, e que estamos repetindo os erros dos applets Java / Flash / ActiveX.
    • Alguns usuários desativam completamente WebGPU/WebGL por segurança/privacidade, aceitando a perda de apps ricos.
  • Corrente favorável/aceitante:
    • Observa que a distribuição de apps nativos em desktops é insegura e fragmentada; navegadores fornecem um sandbox multiplataforma de fato com um modelo de permissões.
    • Aponta que muitos apps modernos (Figma, Canva, ferramentas tipo Maps) dependem de WebGL/WebGPU; desligá-los é uma regressão importante.
    • Alguns argumentam que o WebGPU não expõe uma superfície de fingerprinting significativamente maior do que o WebGL já expunha.

Arquitetura de GPU e notas técnicas

  • Explicação de que GPUs frequentemente não têm preempção fina, no nível do sistema operacional:
    • Estado grande e caro; registradores e memória compartilhados tornam difícil interromper shaders de longa execução.
    • Muitos projetos dependem de yielding cooperativo ou fronteiras de granulação grossa, então um loop apertado pode monopolizar o dispositivo.
  • Discussão sobre limites de loop em shaders: historicamente, loops finitos eram impostos/desenrolados; com fluxo de controle geral, usa-se proteção baseada em timeout.
  • Implementações do WebGPU às vezes injetam grandes contadores regressivos para “garantir” a terminação do loop, mas o contador é tão grande que o sistema ainda pode travar muito antes de o loop terminar.
  • Observações de que um simples loop de compute shader pode derrubar apenas a aba, enquanto combiná-lo com passes de renderização em espera é o que empurra o WindowServer para além do limite; mover o canvas para fora da tela muda o comportamento, sugerindo interações complexas no caminho de composição.

Mitigações e contornos discutidos

  • Desativar WebGPU (e opcionalmente WebGL) globalmente ou por navegador; vários usuários do Firefox mencionam já fazer isso.
  • Usar navegadores que:
    • Perguntem antes de restaurar sessões que travaram, ou
    • Permitam iniciar sem carregar automaticamente todas as abas restauradas.
  • Se preso em um loop de restauração automática: fechar o navegador rapidamente assim que o ícone aparecer, ou desconectar temporariamente da rede; a eficácia da desconexão de rede é debatida, especialmente com service workers.
  • Sugestão de que extensões poderiam substituir as APIs do WebGPU por no-ops em sites não confiáveis.
  • Alguns contam com navegadores/sistemas endurecidos (por exemplo, GrapheneOS Vanadium), que parecem se recuperar de forma mais graciosa.

Paralelos históricos e relatos

  • Numerosas referências a truques web antigos “divertidos” ou maliciosos:
    • Loops infinitos de alert(), tempestades de pop-ups e sites de choque que tocavam áudio em alto volume e spamavam janelas.
    • Bugs antigos de Unicode ou SSID de Wi‑Fi que podiam derrubar dispositivos iOS.
    • Páginas de navegador que forçavam memória/DevTools via logging infinito ou cenas 3D pesadas.
  • Alguns veem o bug atual como parte dessa longa classe de negação de serviço acionada pelo navegador, observando que travamentos de GPU semelhantes já existiam com WebGL e OpenCL anos atrás.