Cloudflare 如何修复 Containers 中的跨租户数据泄露漏洞

# Cloudflare 如何处理 Containers 中的跨租户数据泄露漏洞 来源：https://blog.cloudflare.com/containers-cross-tenant-vulnerability/ 2026年9月4日，来自 Accomplish（https://accomplish.ai/）的安全研究员 Oren Yomtov 通过 Cloudflare 的漏洞赏金计划（https://hackerone.com/cloudflare?type=team）负责任地报告了一个影响 Cloudflare Containers（https://developers.cloudflare.com/containers/）和 Cloudflare Sandboxes（https://developers.cloudflare.com/sandbox/，基于 Containers 构建）的漏洞。Cloudflare 已全面修复该漏洞，且没有证据表明客户数据遭到泄露。 本文是在 Oren Yomtov 和 Accomplish 安全研究团队的协作下撰写的，他们的详细报告和受控测试帮助我们验证了问题并迅速做出响应。 Cloudflare Containers 在多租户基础设施上运行工作负载，并自动将其分配到符合条件的服务器上；客户无法选择底层主机。研究人员证明，拥有 Workers Paid 账户的客户可以恢复同一主机上之前由 Containers 使用过的残留磁盘块。该技术无法针对特定客户、工作负载、主机或数据，且残留数据的存在也并非保证会出现。 Cloudflare 已在整个 Containers 集群上应用了修复方案，无需客户进行任何配置更改。在我们可用的历史磁盘 I/O 遥测数据中，我们没有发现恶意利用的证据。我们能够归因于该报告技术的活动来自研究人员以及进行授权验证的 Cloudflare 工程师。 本文将解释底层的存储行为、其潜在影响、我们的调查过程，以及我们所采取的应对措施。 ## 容器存储分配的工作方式 Cloudflare Containers 使用 Linux device mapper thin provisioning（dm-thin）为每个容器提供可写的根磁盘。每个容器都位于由 Firecracker 虚拟机监控器驱动的专用虚拟机中。Firecracker 将该磁盘以 `/dev/vdc` 的形式呈现给虚拟机。 Thin provisioning 仅在虚拟磁盘写入此前未映射的区域时才分配物理存储。受影响的存储池使用 64 KiB 的 thin 块大小。当支撑容器根磁盘的 thin 卷被删除时，其物理块会被归还到一个服务于多个客户账户工作负载的池中。 受影响的池配置包含以下选项： `skip_block_zeroing` 启用该选项后，dm-thin 在使新分配的块可访问之前会跳过清零操作。因此，当一个此前使用过的 64 KiB 块被重新分配时，完整的块写入会替换其原有内容，但较小的写入只会更改被写入的部分。其余部分可能会保留该块先前所有者的数据。 ## 漏洞利用的工作原理 读取新 thin 磁盘的未映射区域并不会暴露残留数据。对于 thin 设备的未映射区域，`dm-thin` 会在不分配物理块的情况下返回零值。 概念验证识别出与客户机 ext4 文件系统中空闲空间相对应的 64 KiB 对齐区域，并在每个区域中写入一个对齐的 4 KiB 块。 当此类写入触及未映射的 thin 块时，dm-thin 会从共享池中分配一个物理 64 KiB 块。4 KiB 的写入仅替换了该块的这一部分，由于块清零已被禁用，其余 60 KiB 可能会保留先前容器的数据。 因此，随后对原始设备的读取可能观察到新容器从未写入过的字节。 概念验证执行了以下步骤： 1. 使用 Workers Paid 账户创建一个容器。 2. 打开可写的根磁盘 `/dev/vdc`。 3. 读取磁盘并记录基线。 4. 在每个与 ext4 空闲空间相对应的选定 64 KiB 区域中写入一个 4 KiB 块。 5. 再次读取生成的块。 6. 仅检查新容器未覆盖的部分。 提交内容包含计数、块偏移量、大小、校验和结果以及截断的哈希前缀。尽管研究人员恢复了原始块以验证问题，但提供给 Cloudflare 的材料中不包含第三方文件名、标识符、凭据、主机名、地址或恢复的内容值。如后文所述，研究人员还确认他们已安全删除了恢复的数据。 ## 漏洞如何被验证 研究人员使用 ext4 目录块校验和来区分属于他们为概念验证创建的测试文件系统的块与来自其他文件系统的块。 当 ext4 使用 `metadata_csum` 功能时，目录块校验和会纳入与文件系统和 inode 相关联的值。 在六个生产环境中，研究人员报告了以下结果： - 全部 5,614 个可测试的目录块。 - 其中零个块被归因于研究人员的文件系统。 - 通过校验和分析识别出 2,700 个不同的外部目录 inode。 为了验证该方法，研究人员针对他们在概念验证所用受控测试文件系统中故意创建并删除的块进行了测试。该方法正确地将全部 162 个块归因于该文件系统。 研究人员最终在四个大洲的 24 个部署中的 18 个以及 22 个底层节点中的 20 个上观察到了残留材料。恢复的块类型包括目录结构、数据库页面以及结构完整的 SQLite 数据库。研究人员报告称，他们使用了仅输出聚合计数和格式检查结果而非恢复文件内容的脚本。提交给 Cloudflare 的材料不包含任何恢复的内容值或第三方标识符。研究人员随后确认，他们所控制的恢复数据保持机密，并在提交后按照 Cloudflare 的 HackerOne 披露政策进行了安全删除。 ## 影响 该漏洞可能允许拥有 Workers Paid 账户的客户恢复同一底层主机上其他客户的 Containers 此前使用过的存储块中的残留数据。 成功的利用会跨越租户隔离边界，并可能泄露文件系统元数据、目录结构、数据库页面和应用程序数据。 然而，攻击者无法选择特定受害者，也无法访问正在挂载的磁盘。暴露程度取决于 Cloudflare 的工作负载放置方式以及 dm-thin 重新分配了哪些先前释放的块。此外，研究人员**并未**证明可以修改其他客户的活跃数据或影响工作负载的可用性。 ## 我们如何缓解该漏洞 我们的首要缓解措施是在整个集群的 `dm-thin` 池配置中移除 `skip_block_zeroing`。这恢复了 dm-thin 的默认行为，即在将新分配的块暴露给容器之前先进行清零。这阻止了报告的技术——该技术通过较小的写入触发分配，再通过较大的读取从块的其余部分恢复残留数据。研究人员独立确认，此次更改后他们的概念验证不再有效。 对新分配的块进行清零并不能清理已映射到现有 thin 设备中的块。这些映射存在于运行中的容器磁盘以及每台主机为 OCI 镜像层准备的 dm-thin 快照缓存中。新容器可以从缓存层继承映射，而无需再次分配这些块，从而使得未使用区域（包括 ext4 空闲空间）中的残留字节仍可通过 `/dev/vdc` 的原始读取被读取。 因此，我们还退役了所有正在运行的容器磁盘，并移除了缓解措施之前创建的缓存镜像快照。我们在非高峰时段排空主机，重启每台主机上的虚拟机，并清除每台主机的镜像缓存，以便磁盘和缓存层使用清零后的分配重新创建。我们已在整个 Containers 集群完成了此清理工作。 ## 没有利用的证据 作为响应的一部分，我们调查了其他工作负载是否显示出与所报告的利用技术一致的活动。我们审查了容器基础设施保留的历史磁盘 I/O 遥测数据，并以研究人员的概念验证和我们的内部复现作为参考活动。 概念验证在写入和读入之间产生了特征性关系。当 4 KiB 的写入触及此前未映射的区域时，可能会触发对一个被重新使用的 64 KiB 存储块的分配。在禁用清零的情况下，其余 60 KiB 可能会保留先前容器的数据。因此，后续读取可能恢复比新容器覆盖的数据多得多的内容。 利用这些特征，我们开发了检测签名，并将其应用于我们可用的历史遥测数据中。我们识别出了可归因于研究人员和进行授权验证的 Cloudflare 工程师的活动，但未发现其他与所报告技术一致的额外活动。 我们没有发现任何其他人利用此特定攻击向量的证据。 ## Cloudflare 客户已受保护 如上所述，Cloudflare 已修补此漏洞，且修复过程无需 Cloudflare 客户采取任何进一步操作。此外，我们没有发现任何恶意行为者滥用此漏洞的证据。 ## 以透明方式快速行动 我们感谢 Oren Yomtov 和 Accomplish 安全研究团队的深入研究、负责任的披露以及在本文撰写过程中的协作。我们鼓励 Cloudflare 社区提交任何发现的漏洞，以帮助我们持续改进产品和平台的安全状况。 我们也认识到，您对我们的信任对于您的基础设施在 Cloudflare 上的成功至关重要。我们非常重视这些漏洞，并将继续尽一切努力缓解其影响。我们衷心感谢您对我们平台的持续支持和信任，并将继续致力于不仅在我们所做的一切中优先考虑安全，而且在出现问题时迅速而透明地采取行动。 ## 时间线 - 9月4日 15:26 UTC：来自 Accomplish（https://accomplish.ai/）的 Oren Yomtov 通过 HackerOne（https://hackerone.com/reports/3997565）报告了该问题。 - 9月4日 18:45 UTC：Cloudflare 启动了安全事件响应，并确认了导致该缺陷的生产环境配置。 - 9月4日 21:27 UTC：Cloudflare 合并了运行时修复及其复用测试。 - 9月4日 22:03 UTC：Cloudflare 合并了针对新池和现有池的更改。 - 9月4日 23:15 UTC：Cloudflare 开始推出这些更改。 - 9月7日 06:13 UTC：Cloudflare 完成更改的推出，并开始清理旧池数据。 - 9月14日 10:50 UTC：研究人员报告称，他们的概念验证已停止工作。 - 9月14日 12:52 UTC：Cloudflare 向研究人员发放了赏金。 - 9月19日 15:03 UTC：Cloudflare 完成了受影响集群中所有缓解措施之前缓存的快照的清理工作。