Cloudflare 修复容器跨租户数据泄露漏洞，源于存储分配器跳过清零操作

一句话结论

Cloudflare Containers 因存储配置缺陷允许付费用户读取其他租户遗留磁盘块，该跨租户数据泄露漏洞已修复且无恶意利用证据。

关键要点

• 漏洞根因是 dm-thin 存储分配器配置了 skip_block_zeroing 选项，导致新分配的 64 KiB 物理块未清零。
• 攻击者写入 4 KiB 数据可触发分配 64 KiB 块，剩余 60 KiB 空间保留其他客户容器释放前的数据。
• 研究人员在 6 个生产环境部署的 5614 个可测试目录块中，识别出 2700 个来自其他用户的外部目录索引节点。
• 受影响资源池覆盖四大洲 24 个部署点及 22 个底层节点，其中 18 个部署点和 20 个节点发现残留数据。
• Cloudflare 在 9 月 7 日完成修复部署，9 月 19 日完成历史残留数据清理，9 月 14 日向研究员发放赏金。

背景与事实

Cloudflare 近期披露其 Containers 平台存在跨租户数据泄露漏洞，该漏洞同样影响提供沙箱功能的 Cloudflare Sandboxes 产品。每个 Cloudflare 容器都在 Firecracker 虚拟机中运行，虚拟机配备可写入根磁盘，并通过 Linux 设备映射器（device mapper）的精简配置机制管理。受影响的资源池采用 64 KiB 的精简块大小，并启用了 skip_block_zeroing 选项。该选项指示 dm-thin 在对外暴露新分配块前跳过清零操作，这一性能优化配置直接导致了安全边界失效。

Accomplish 公司安全研究员 Oren Yomtov 于 9 月 4 日通过 Cloudflare 漏洞赏金计划报告了该问题。漏洞机制在于，向未映射区域写入单个 4 KiB 块时，dm-thin 会从跨客户账户共享的资源池中分配一个 64 KiB 物理块。由于写入操作仅覆盖 4 KiB 空间，剩余多达 60 KiB 的空间仍保留之前容器写入的内容。因此，对磁盘进行原始读取时，可能返回新容器从未写入过的字节。研究人员利用 ext4 目录块校验和区分自有数据与外部数据，在测试中成功恢复了目录结构、数据库页以及结构完整的 SQLite 数据库。

Cloudflare 明确表示该漏洞存在严格限制：攻击者无法选择受害者、工作负载或主机，无法读取正在连接的磁盘，也无法保证残留数据一定存在。数据暴露程度取决于 Cloudflare 将工作负载部署到具体位置，以及 dm-thin 恰好重新分配了哪些已释放块。研究人员未演示篡改其他客户数据的能力，也未展示对系统可用性的影响。漏洞报告于 9 月 4 日 15:26（UTC）提交，Cloudflare 于 18:45 创建工单，21:27 合并运行时修复程序，22:03 合并针对新资源和在线资源池的更改，23:15 开始分批部署，9 月 7 日全部完成。移除 skip_block_zeroing 仅恢复新分配块行为，未清理已映射到现有精简块设备的历史数据，因此 Cloudflare 停用运行中容器磁盘，在非高峰时段清空主机数据，重启虚拟机并清空镜像缓存，该清理工作于 9 月 19 日完成。

影响分析

对中文开发者而言，这一事件揭示出共享基础设施租户隔离的核心风险点往往不在网络或应用层，而在底层存储分配机制。使用容器或无服务器平台的团队不能仅依赖供应商提供的网络隔离，必须将共享存储上的残留数据视为首要隔离控制项。分析判断认为，技术团队应建立验证机制，确认每个被重复使用的卷路径在分配时是否经过清零，而非假设释放的块在重新使用前已被清空。该漏洞提醒从业者，在评估平台安全性时，需关注性能优化选项对安全边界的影响，特别是 skip_block_zeroing 这类以性能换取安全的配置项。

适用边界

该结论不适用于私有化部署的独立主机环境，因为漏洞根源在于跨客户共享资源池中的 dm-thin 存储分配器配置。攻击者无法主动触发残留数据暴露，数据是否存在取决于 Cloudflare 的具体部署位置和块重新分配情况，因此不具备可预测性和可重复性。对于不使用 Cloudflare Containers 或 Cloudflare Sandboxes 的平台，该漏洞无直接影响，但同类存储配置风险需在各自基础设施中独立验证。

孤本观察

Firecracker 虚拟机边界经受住考验，漏洞暴露位置在边界之下的块分配器，说明安全架构中“隔离”概念需逐层验证而非停留在架构声明层面。此次事件表明，性能优化与租户隔离之间存在直接冲突，运维团队需将存储层清零机制纳入常规安全审计范围。

来源：InfoQ 中文 AI