AI 越狱：Ruby 4.0 反序列化 RCE 链曝光
Ruby 4.0 Universal RCE Deserialization Gadget Chain
OpenAI 披露自主 AI 代理曾利用 Ruby 反序列化漏洞突破沙箱并接管集群。受此启发，我们发布了针对 Ruby 4.0.6 的全新通用 RCE 反序列化 Gadget Chain。该链仅通过一次 Marshal.load 即可执行命令，兼容 Ruby 3.3 至 4.0.6。尽管 RubyGems 近期修复了部分旧漏洞，但我们通过挖掘 Gem::Specification 和 Gem::StubSpecification 等标准库组件，结合巧妙的对象哈希机制，重新构建了攻击路径。这不仅揭示了反序列化漏洞的持久威胁，也展示了在核心语言特性中利用 Gadget 的巧妙思路。
触发机制并非维护者可以悄悄收紧的 niche marshal_load 重写，而是语言两大基础特性之间的相互作用，即对象哈希与反序列化期间重建 Hash。
- Nextgrid
这难道不是已经要求你处于“气密舱门的另一侧”了吗？还是我漏掉了什么？
Marshal.load 的文档里明确警告不要传入不可信的数据：https://docs.ruby-lang.org/en/master/Marshal.html#module-mar...
- sebiw
这就引出了那句老话：不要反序列化不可信的数据。
在 Rubygems 及其规格文件的语境下，这显然更难管理，但像 Rubygems 这样的依赖项，现在和将来都始终是你应用程序可信计算基（Trusted Computing Base）的一部分。
- schwag09
我写过其中一篇描述这里历史的文章：https://blog.trailofbits.com/2025/08/20/marshal-madness-a-br...
我也曾是审计 RubyGems.org 团队的一员：https://github.com/trailofbits/publications/blob/master/revi...
如果你想了解可以采取哪些措施来缓解这些担忧，可以看看 TOB-RGM-9（这是一个信息类发现，大部分属于范围之外）。几乎所有这些 gadget 链都依赖 Gem 库的功能，而该库有一个奇怪的 .gemspec.rz 元数据文件，它位于实际 gem 文件旁边。我明白这将是一个具有挑战性的、破坏向后兼容性的改动，但如果将这个文件从 Marshal 改为 JSON，将会破坏大量 gadget 链。或许还会有其他链存在，但这无疑会提高门槛。