The Deathray: Una forma sencilla para que un sitio no confiable congele un Mac

Artículo original ↗ Discusión en Hacker News ↗

Un exploit de WebGPU recién señalado puede congelar de forma fiable máquinas macOS —y algunos dispositivos Android— simplemente al visitar una página web especialmente diseñada, en algunos casos obligando a reinicios forzados y a bloqueos repetidos cuando los navegadores restauran pestañas automáticamente. Los comentaristas debaten si este tipo de denegación de servicio debe considerarse una vulnerabilidad de seguridad seria, señalando el potencial de estafas tipo ransomware, pérdida de datos y daño a usuarios no técnicos que no pueden identificar fácilmente la causa. El incidente también alimenta una crítica más amplia a exponer cada vez más funciones de GPU y hardware a la web, enfrentando el rendimiento y las aplicaciones web ricas contra una mayor superficie de ataque e inestabilidad del sistema.

Comportamiento observado y gravedad

  • Muchos usuarios de macOS informan bloqueos completos del sistema: el cursor puede moverse, pero la interfaz, Forzar salida y la entrada no responden; a menudo requiere apagar a la fuerza.
  • En algunos Mac solo mata Safari o la pestaña; cerrar el navegador restaura inmediatamente el funcionamiento normal.
  • Unos pocos informes extremos: fallos repetidos al iniciar sesión debido a pestañas restauradas automáticamente; un usuario inicialmente no podía arrancar ni en modo seguro y necesitó una actualización/reinstalación antes de recuperarse.
  • En otros sistemas el comportamiento es mixto:
    • Algunos navegadores en Windows solo congelan la pestaña o todas las pestañas brevemente y luego matan la página ofensiva.
    • Algunos dispositivos Android (p. ej., Pixel, Samsung) supuestamente se congelan por completo; otros con navegadores distintos o compilaciones endurecidas del sistema operativo solo ven breves tirones o nada.
    • Los casos en Linux/Firefox van desde un navegador que se cierra con fallo hasta ningún impacto visible.
  • Se informa que iOS no se ve afectado; macOS 27 RC sigue afectado.

Debate sobre seguridad y modelo de amenaza (DoS)

  • Preocupa mucho que una congelación fiable provocada por el navegador sea una denegación de servicio significativa y, por tanto, un problema de seguridad.
  • Casos de abuso sugeridos: scareware (“tu ordenador se congeló por un virus”), extorsión tipo rescate (“seguiremos congelándote a menos que…”), coacción de ad-tech (“desactiva el bloqueador de anuncios o bloqueamos tu máquina”), estafas de falso antivirus más creíbles porque la máquina realmente se congeló.
  • Otros argumentan que “solo” afecta a la disponibilidad, no roba datos ni escala privilegios, así que tiene menor prioridad.
  • Desacuerdo sobre el comportamiento del usuario:
    • Una postura afirma que se “autocorrige” porque los usuarios evitan los sitios que los congelan.
    • Otros responden que los usuarios normales no vincularán congelación ↔ sitio, quedarán atrapados en bucles de restauración automática o acabarán llamando a estafadores de “soporte técnico”.

Responsabilidad: SO vs navegador vs WebGPU

  • Algunos lo presentan principalmente como un fallo de macOS: otros sistemas operativos tienen watchdogs de GPU que reinician cargas de trabajo problemáticas; macOS sigue permitiendo que los bloqueos de la GPU derriben todo el sistema/WindowServer.
  • Otros lo ven como algo inherente a WebGPU/WebGL: la web nunca debería poder bloquear una máquina, independientemente del comportamiento del sistema operativo.
  • El hilo señala que Apple ha cerrado problemas similares de WebGPU como “no relevantes para la seguridad”.

Visiones más amplias sobre WebGPU y la web como plataforma de aplicaciones

  • Postura escéptica:
    • Preocupación por una superficie de ataque de hardware en expansión en los navegadores (WebGPU, WebUSB, etc.).
    • Argumentan que los navegadores eran para documentos, no como una capa completa de aplicación/entorno de ejecución, y que estamos repitiendo los errores de Java applets / Flash / ActiveX.
    • Algunos usuarios desactivan WebGPU/WebGL por completo por seguridad/privacidad, aceptando perder aplicaciones ricas.
  • Postura favorable/aceptante:
    • Señalan que la distribución de aplicaciones nativas en escritorio es insegura y fragmentada; los navegadores proporcionan una sandbox multiplataforma de facto con un modelo de permisos.
    • Indican que muchas aplicaciones modernas (Figma, Canva, herramientas similares a Maps) dependen de WebGL/WebGPU; desactivarlos supone una gran regresión.
    • Algunos sostienen que WebGPU no expone una superficie de fingerprinting significativamente mayor que la que ya ofrecía WebGL.

Arquitectura de GPU y notas técnicas

  • Explicación de que las GPUs a menudo carecen de preempción fina a nivel de SO:
    • Estado grande y costoso; los registros y la memoria compartidos hacen difícil interrumpir shaders de larga duración.
    • Muchos diseños dependen de ceder cooperativamente o de límites gruesos, así que un bucle apretado puede monopolizar el dispositivo.
  • Debate sobre los límites de bucles de shaders: históricamente se imponían/desenrollaban bucles finitos; con control de flujo general, se usa protección basada en tiempo de espera.
  • Algunas implementaciones de WebGPU inyectan enormes contadores descendentes para “garantizar” la terminación del bucle, pero el contador es tan grande que el sistema aún puede congelarse mucho antes de que el bucle termine.
  • Observaciones de que un simple bucle de shader de computación puede hacer caer solo la pestaña, mientras que combinarlo con pasadas de renderizado en espera es lo que empuja a WindowServer al límite; mover el canvas fuera de pantalla cambia el comportamiento, lo que sugiere interacciones complejas en la ruta de composición.

Mitigaciones y soluciones provisionales discutidas

  • Desactivar WebGPU (y opcionalmente WebGL) globalmente o por navegador; varios usuarios de Firefox mencionan que ya lo hacen.
  • Usar navegadores que:
    • Pregunten antes de restaurar sesiones fallidas, o
    • Permitan iniciar sin cargar automáticamente todas las pestañas restauradas.
  • Si quedas atrapado en un bucle de restauración automática: cerrar rápidamente el navegador en cuanto aparezca su icono, o desconectar temporalmente la red; la eficacia de desconectar la red se debate, especialmente con service workers.
  • Sugerencia de que las extensiones podrían reemplazar las APIs de WebGPU por no-op en sitios no confiables.
  • Algunos confían en navegadores/SO endurecidos (p. ej., GrapheneOS Vanadium), que parecen recuperarse con más gracia.

Paralelos históricos y anécdotas

  • Numerosas referencias a trucos web anteriores “divertidos” o maliciosos:
    • Bucles infinitos de alert(), tormentas de popups y sitios de susto que reproducían audio a todo volumen y enviaban ventanas emergentes en masa.
    • Antiguos fallos de Unicode o de SSID Wi‑Fi que podían bloquear dispositivos iOS.
    • Páginas de navegador que estresaban la memoria/DevTools mediante registro infinito o escenas 3D pesadas.
  • Algunos ven el fallo actual como parte de esta larga clase de DoS provocados por el navegador, y señalan que hace años ya existían bloqueos de GPU similares con WebGL y OpenCL.