Google Chrome 120.0.6099.224 之前 V8 中的越界内存访问

原文 ↗ Hacker News 讨论 ↗

Chrome 的 V8 JavaScript 引擎中新披露的越界内存访问漏洞（CVE-2024-0519）已知正在被野外利用，引发了人们对浏览器、Node.js、Electron 应用以及其他嵌入 V8 的软件安全性的担忧——尤其是在未打补丁或像 Windows 7 这样的遗留系统上。评论者探讨了 JIT 编译器的复杂性、内存不安全语言以及 fuzzing 的局限性为何让这类微妙漏洞即使对资源充足的团队也难以防范。该讨论还审视了“受信任”与“不受信任”代码的含义、沙盒在现实中的价值，以及禁用 JIT 或采用更高层次或形式化验证工具是否能切实降低风险。

CVE 映射与补丁

  • 评论者试图定位确切的 git diff；提到了多个候选提交和 bug 编号，且 CVE-2024-0517、-0518 和 -0519 之间存在一些混淆。
  • 一位参与者指出，Chrome 的发布说明把 0519 关联到与某个建议提交不同的问题编号，因此精确映射仍然有些不清楚。
  • Fedora 的安全公告提到三个独立的 V8 CVE（类型混淆、越界读取、越界写入），这表明同一时期存在多个编译器/运行时问题。

受影响的版本与产品

  • NVD 的 CPE 列表似乎表示影响可追溯到 Chrome 9，但有人强调这些范围通常未经验证，而且显然可能是错误的（例如，一个 WebGPU 漏洞“影响”到 WebGPU 尚不存在之前的版本）。
  • 由于该漏洞似乎与 Maglev 编译器有关，而 Maglev 大约在 Chrome 114 左右才引入，因此较旧的 Chrome 版本（如 60）很可能不受影响，不过这只是推断而非确认。
  • 由于这三个 CVE 都在 V8 中，任何嵌入 V8 的东西（Node.js、Electron 应用、自定义嵌入器、无服务器/边缘平台）如果运行不受信任或半受信任的 JavaScript，都可能暴露在风险之下。

不受信任的代码、沙盒与影响

  • 关于“untrusted code（不受信任的代码）”的含义存在争论：
    • 一种观点：任何没有被彻底审计的代码都不可信，因此典型的 Node 依赖栈都算。
    • 另一种观点：如果你把它放在自己的进程里运行，你实际上就是在信任它；“不受信任”的代码是你预期它可能是恶意的、必须放进沙盒里的代码。
  • 浏览器和许多应用高度依赖 V8 作为应对恶意输入的沙盒；这类漏洞会削弱这一假设。
  • 漏洞利用分析（针对 0517）通过基于 Wasm 的利用链，在 V8/“Ubercage” 沙盒内实现了强大的读写能力；公开利用链看起来并没有破坏 Chrome 外层的操作系统级沙盒。
  • 有人指出，即使只是沙盒内代码执行，也可能泄漏或去匿名化用户，具体取决于平台细节。

JIT、Fuzzing 与语言安全

  • 多条评论强调，尽管 Chrome/V8 对 fuzzing 的投入很大，但 fuzzing 具有随机性，可能多年都错过深层漏洞。
  • 也有人认为，无论实现语言是什么，JIT 引擎都可能发生错误编译；内存安全语言并不能消除这类问题，尽管它们能消除其他大量原始内存错误。
  • 讨论中还提到了替代设计：更安全的解释器、禁用 JIT（主流浏览器都支持）、以及更高层的 JIT 框架（例如 Graal/Truffle 风格），以减少手动操作 IR。
  • 共识是：没有人知道如何构建大型、高性能且零安全漏洞的 JIT 和浏览器；内存安全语言有帮助，但并不是完整解决方案。

威胁模型与运营风险

  • 讨论区分了“无聊的五岁小孩”（低成本攻击者）和民族国家；后者通常即使面对强防御也能得手。
  • 现实世界中大多数入侵仍源于极其简单的错误（未打补丁的软件、糟糕的密码），而不是新的 V8 0day，因此对大多数组织来说，及时更新更重要。
  • 大家也对漏洞经纪人把这类漏洞卖给政府，以及大量浏览器未打补丁的现状感到不安。

遗留系统与长期暴露

  • Windows 7 上的 Chrome 被锁定在 109 版本；这些系统不会收到新 V8 漏洞的修复。
  • 有人认为在网络中运行 Windows 7 的人“根本不在乎安全”；也有人反驳说，一台隔离且受防火墙保护的 Windows 7 机器主要可能只通过其浏览器暴露。
  • 有观点指出 Windows 7/8/XP 仍占有不小的市场份额，这让人担心存在一个规模庞大、永久易受攻击的安装基数。