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