Cloudflare's cross-tenant disk leak can't be disproven, and that's the part worth worrying about
Most cross-tenant leak stories end with a headline number and a shrug. The one Cloudflare just disclosed in its Containers and Sandboxes platform is worth actually reading, because the bug lives in a decision a lot of storage engineers make on purpose. When a container's root disk was deleted, the underlying thin volume's physical 64 KiB blocks were handed back to a shared dm-thin storage pool that served multiple customer accounts on the same host. That pool was configured to skip zeroing the blocks it reused, so a customer on a Workers Paid account could nudge a small write at the right moment, allocate a freshly recycled block, and read the roughly 60 KiB of whatever the previous tenant left behind. Accomplish's Oren Yomtov, who reported it through the bug bounty in September, showed the technique pulling directory listings, SQLite databases, Chromium profiles, .env files, and credential files out of other people's workloads. No targeting, no guarantee the data was even there, just the luck of the physical allocation.
Cloudflare fixed it across the whole fleet with no customer-side changes, and its historical disk-I/O telemetry shows nothing that looks like an active exploit. Fine. But that "no evidence of exploitation" is doing a lot of work in the writeup, and it deserves a skeptic's eyebrow. The telemetry can tell you a write hit a block; it can't tell you what a reader did with the bytes it pulled out. The exposure window was structural, not an attack: for however long skip_block_zeroing was live, any tenant that happened to land on a freshly recycled block next to yours was reading your leftovers with a perfectly legitimate disk read, leaving no incident, no alert, and no breadcrumb to reconstruct after the fact. One tenant's .env or a database file surfacing as stale slack on a neighbor's volume isn't a breach you can scope, notify, or even confirm. It's the kind of thing that, if it happened, is already true.
The deeper lesson is that a perf-for-correctness trade has a fine line, and multi-tenant infrastructure draws it on you. Skipping block zeroing on reuse is a legitimate latency win the moment your substrate is single-tenant. The instant it's shared, the failure mode flips from "I read my own stale block" (harmless) to "I read my neighbor's secrets," and the only thing standing between you and a silent exfiltration is that nobody was motivated to do the math. That's the same class of bug as shred-before-you-sell-the-drive, just moved to a scale where the drive never ships and the forensics never catch up. So the question I keep coming back to: if your most sensitive data ever passed through a shared multi-tenant host, what would actually convince you it had not been read by a neighbor? Telemetry seems like a weak answer.
Sources
Comments
Post a Comment