The Deathray：一种让不受信任的网站冻结 Mac 的简单方式

原文 ↗ Hacker News 讨论 ↗

一个新近引起关注的 WebGPU 漏洞，只需访问一个特制网页，就能可靠地冻结 macOS 机器——在某些情况下甚至会影响部分 Android 设备——并在浏览器自动恢复标签页时导致反复死锁，迫使用户硬重启。评论者争论这类拒绝服务是否应被视为严重的安全漏洞，指出其可能被用于类似勒索软件的诈骗、数据丢失，以及对不懂技术、又难以识别根因的用户造成伤害。这一事件也进一步引发了对向 Web 暴露越来越多 GPU 和硬件功能的广泛批评，在性能与丰富 Web 应用之间，与攻击面扩大和系统不稳定形成对立。

观察到的行为与严重性

  • 许多 macOS 用户报告出现整个系统卡死：光标可能仍能移动，但 UI、强制退出和输入都无响应；通常需要强制断电。
  • 在某些 Mac 上，它只会让 Safari 或标签页崩溃；退出浏览器后会立即恢复正常。
  • 也有少数极端报告：由于自动恢复标签页，登录时反复崩溃；一位用户最初甚至无法在安全模式下启动，必须先更新/重装才能恢复。
  • 非 mac 行为则不一致：
    • 一些 Windows 浏览器只是让标签页或所有标签页短暂卡住，然后杀掉有问题的页面。
    • 一些 Android 设备（如 Pixel、Samsung）据称会完全冻结；而其他使用不同浏览器或强化版 OS 构建的设备则只会短暂卡顿或毫无影响。
    • Linux/Firefox 的情况从浏览器崩溃到没有可见影响都有。
  • 据报道 iOS 不受影响；macOS 27 RC 仍然受影响。

安全性与威胁模型争论（DoS）

  • 有人强烈担心：一种可由浏览器可靠触发的冻结是有意义的拒绝服务，因此属于安全问题。
  • 可能的滥用方式包括：恐吓软件（“你的电脑因病毒而冻结了”）、勒索式威胁（“除非……否则我们会一直让它冻结”）、广告技术胁迫（“关闭 adblock，否则我们让你的机器崩溃”），以及因为机器确实冻结过而更逼真的假杀毒骗局。
  • 也有人认为这“只是可用性问题”，没有数据窃取或提权，因此优先级较低。
  • 对用户行为存在分歧：
    • 一方声称它会“自我纠正”，因为用户会避开会让自己冻结的网站。
    • 另一方反驳说，普通用户不会把“冻结”与“网站”联系起来，会陷入自动恢复循环，或者被“技术支持”骗子诱导。

责任归属：OS vs 浏览器 vs WebGPU

  • 有人主要将其视为 macOS bug：其他操作系统有 GPU watchdog 可以重置行为异常的工作负载；而 macOS 仍然会让 GPU hang 拖垮整个系统/WindowServer。
  • 另一些人则认为这本质上是 WebGPU/WebGL 的问题：无论 OS 行为如何，Web 都不应该能锁死一台机器。
  • 线程中提到，Apple 已将类似的 WebGPU 问题以“与安全无关”关闭。

对 WebGPU 以及 Web 作为应用平台的更广泛看法

  • 持怀疑态度的一方：
    • 担心浏览器中的硬件攻击面不断扩大（WebGPU、WebUSB 等）。
    • 认为浏览器本该用于文档，而不是作为完整的应用/运行时层；我们正在重演 Java applet / Flash / ActiveX 的错误。
    • 一些用户会出于安全/隐私考虑完全禁用 WebGPU/WebGL，接受丰富应用能力下降的代价。
  • 持支持/接受态度的一方：
    • 指出桌面端原生应用分发不安全且碎片化；浏览器事实上提供了跨平台的沙箱和权限模型。
    • 提醒说许多现代应用（Figma、Canva、类似地图的工具）都依赖 WebGL/WebGPU；关闭它们会造成重大倒退。
    • 也有人认为 WebGPU 并不会比 WebGL 已经暴露的指纹识别面更大多少。

GPU 架构与技术说明

  • 解释指出 GPU 往往缺乏细粒度、OS 级别的抢占：
    • 状态庞大且昂贵；共享寄存器和内存使得中断长时间运行的 shader 变得困难。
    • 许多设计依赖协作式让出或粗粒度边界，因此紧密循环可以垄断设备。
  • 关于 shader 循环限制的讨论：历史上曾强制/展开有限循环；随着通用控制流出现，现在改用基于超时的保护。
  • WebGPU 实现有时会注入巨大的递减计数器来“保证”循环终止，但这个计数器大到即使循环还未结束，系统也可能早已卡死。
  • 观察到一个简单的 compute shader 循环可能只会让标签页崩溃，而把它与等待中的渲染 pass 结合起来才会把 WindowServer 推到极限；将 canvas 移到屏幕外会改变行为，这表明合成路径中存在复杂交互。

讨论中的缓解与变通方法

  • 全局或按浏览器禁用 WebGPU（以及可选的 WebGL）；一些 Firefox 用户提到自己已经这样做了。
  • 使用以下浏览器：
    • 在恢复崩溃会话前提示，或
    • 允许在不自动加载所有已恢复标签页的情况下启动。
  • 如果陷入自动恢复循环：在浏览器图标一出现时就快速退出，或者临时断开网络；断网是否有效存在争议，尤其在有 service workers 的情况下。
  • 有人建议扩展可以在不受信任的网站上把 WebGPU API stub 成 no-op。
  • 有些人依赖强化版浏览器/操作系统（例如 GrapheneOS Vanadium），看起来恢复得更优雅。

历史类比与轶事

  • 多次提到早年的“有趣”或恶意 Web 把戏：
    • 无限 alert() 循环、弹窗风暴，以及会狂放音频并刷窗的 shock site。
    • 旧时会让 iOS 设备崩溃的 Unicode 或 Wi-Fi SSID bug。
    • 通过无限日志或沉重的 3D 场景来压垮内存/DevTools 的浏览器页面。
  • 一些人认为当前 bug 属于这类长期存在的浏览器驱动 DoS 的一部分，并指出多年前 WebGL 和 OpenCL 中也存在类似的 GPU hang。