Cloudflare 修复容器跨租户数据泄露漏洞

Cloudflare Containers 平台因 device mapper 的精简配置中启用 skip_block_zeroing 且块大小为 64 KiB，导致跨租户磁盘块残留数据可被读取。漏洞根因在存储分配器而非虚拟机隔离层，已修复且无已知利用。

设备映射器 skip_block_zeroing + 64 KiB 精简块引发残留数据暴露

漏洞不依赖 VM 边界失效，纯属存储层清零逻辑缺失

单次 4 KiB 写入触发 64 KiB 块分配，剩余空间未初始化即暴露

适合云平台工程师、容器运行时开发者、云安全架构师阅读

Cloudflare 最近披露了其 Containers 平台中存在的一个跨租户数据泄露漏洞。该平台也为 Cloudflare Sandboxes 提供支持。Workers 付费账户的客户可以恢复同一主机上其他客户容器遗留的磁盘块。Cloudflare 已经修复了这个漏洞，并表示未发现任何该漏洞被恶意利用的证据。该漏洞并非出在虚拟机边界上，而是源于其底层的存储分配器。

Accomplish 公司安全研究员 Oren Yomtov 于 9 月 4 日通过 Cloudflare 的漏洞赏金计划报告了该问题。

每个 Cloudflare 容器都在一个 Firecracker 虚拟机中运行。该虚拟机具有可写入的根磁盘，并通过 Linux 设备映射器（device mapper）的精简配置机制进行配置。受影响的资源池使用了 64 KiB 的精简块大小，并且配置了 skip_block_zeroing 选项。该选项会指示 dm-thin 在对外暴露新分配的块之前不对其执行清空操作。

正是这种组合导致了安全漏洞。向未映射区域写入单个 4 KiB 块时，会导致 dm-thin 从跨客户账户共享的资源池中分配一个 64 KiB 的物理块。该写入操作仅覆盖了自身占用的 4KiB 空间，剩余多达 60 KiB 的空间仍然可能保留着之前容器写入的内容。因此，对磁盘进行原始读取时，就可能会返回新容器从未写入过的字节。

研究人员利用 ext4 目录块校验和，将自己写入的块与其他所有人的块区分开来。在六个生产环境部署中，所有 5614 个可测试的目录块均来自其他用户，共识别出 2700 个不同的外部目录索引节点。在横跨四大洲的 24 个部署点以及 22 个底层节点中，分别有 18 个和 20 个发现了残留数据。成功恢复的块类型包括目录结构、数据库页以及结构完整的 SQLite 数据库。

Cloudflare 对这些限制做了明确说明：攻击者无法选择受害者、工作负载或主机，无法读取正在连接的磁盘，也无法保证残留数据是否存在。数据暴露取决于 Cloudflare 将工作负载部署到了什么位置，以及 dm-thin 恰好重新分配了哪些已释放的块。研究人员并未演示如何篡改其他客户的数据，也未展示任何对可用性的影响。

在 LinkedIn 上，安全从业者的讨论重点并不是平台本身，而是隔离机制在何处出现了故障。Visa 高级云安全工程师 Peter Ward 指出，这种情况会反复出现：

这是存储层的租户隔离机制失效，而非应用程序 Bug。

他认为，对于临时磁盘和共享主机，控制平面应明确实施“分配时清零”或“释放时擦除”检查，而不能仅依赖网络隔离；他还提供了一个测试方法，团队可以将其应用于任何容器或无服务器平台：检查每个被重复使用的卷路径是否在分配时进行了清零，并将共享存储上的残留数据视为首要的隔离控制项。

从事云计算和网络安全领域工作的技术专家 Sherin Shahanas 指出，根本原因很少得到验证：

“隔离”通常只是架构层面的说法，而不是在存储层做过单独测试的内容。

对于运行任何共享基础设施类型（无论是容器、虚拟机还是共享虚拟化集群）的团队，他提了一个问题：他们是否知道，还是仅仅假设，已经释放的块在被重新使用前已经清零了。

这个问题提得恰逢其时。该漏洞披露恰好发生在两款产品发布之间：微软正式发布 Azure Container Apps Sandboxes，称每个工作负载都在硬件隔离的微虚拟机（microVM）边界内运行；谷歌则发布了 GKE Pod 快照的基准测试结果——该功能可以利用 gVisor 对内存和磁盘进行检查点备份，并将结果存储在 Cloud Storage 中。这两家供应商都在为执行不可信代码的智能代理工作负载提供隔离方案。Cloudflare 的漏洞披露提醒我们，保障范围不只涉及公告中提到的层级，还包括那些层级之下的所有层级，包括块分配器。

如果这些反应具有代表性，那么从业者从中得出的教训在于关注验证环节，而不单是供应商选择。Firecracker 的边界经受住了考验。数据泄露问题出在边界之下。具体来说，是某个性能优化选项跳过了块复用时的清零操作。

Cloudflare 的响应非常迅速，但时间线显示，仅靠修复是不够的。该报告是 9 月 4 日 15（UTC）收到的。Cloudflare 于 18 创建了事件工单，21 合并了运行时修复程序，22 合并了针对新资源池和在线资源池的更改，并于当天 23 开始分批部署。部署于 9 月 7 日全部完成。

移除 skip_block_zeroing 恢复了新分配块的默认行为，但并未清理已映射到现有精简块设备中的块——无论这些块位于正在运行的容器磁盘中，还是位于各主机为 OCI 镜像层准备的快照缓存中。新容器可能会继承这些映射关系，而不是重新分配这些块。因此，Cloudflare 停用了所有正在运行的容器磁盘，在非高峰时段清空了主机数据，重启了虚拟机，并清空了每台主机的镜像缓存。该清理工作已于 9 月 19 日完成。

Cloudflare 表示，在发现该问题后，他们根据“先进行小规模写入，后进行大规模读取”这一特征模式构建了检测签名，并将其应用于留存的历史磁盘 I/O 遥测数据。分析结果显示，仅有研究人员以及他们自己的工程师在进行授权验证时产生的活动符合该模式。

研究人员证实，变更生效后，他们的概念验证已经无法正常运行。而且，在研究人员提交漏洞报告后，在他们控制下恢复的数据已经被安全地删除。Cloudflare 于 9 月 14 日发放了赏金。

原文链接：https://www.infoq.com/news/2026/10/cloudflare-cross-tenant-exposure/