Cloudflare ripara vulnerabilità di cross-tenant nei container, dati sensibili potenzialmente esposti

Cloudflare ha risolto una falla di sicurezza nel suo servizio Containers, che supporta anche Cloudflare Sandboxes. La vulnerabilità permetteva a un cliente di recuperare blocchi di disco lasciati da altri clienti sullo stesso host. La falla non riguardava il confine tra macchine virtuali, ma lo strato di allocazione dello storage sottostante. Il bug è stato segnalato il 4 settembre da ricercatori di Accomplish tramite il programma di premiazione per le vulnerabilità di Cloudflare. Ogni container Cloudflare gira all'interno di una macchina virtuale Firecracker con disco radice scrivibile, configurato tramite meccanismo di thin provisioning di Linux device mapper. Le risorse colpite usavano una dimensione del blocco sottile di 64 KiB e l'opzione skip_block_zeroing, che istrutta dm-thin a non azzerare i blocchi prima di renderli disponibili. Questa combinazione ha causato la falla: scrivere un singolo blocco da 4 KiB in una zona non mappata portava dm-thin a allocare un blocco fisico da 64 KiB dalla pool condivisa. Di conseguenza, fino a 60 KiB di dati residui di altri container potevano essere letti tramite accesso grezzo al disco. I ricercatori hanno utilizzato checksum del blocco del directory ext4 per distinguere i propri blocchi, trovando 2700 directory index node univoche su 5614 blocchi testati in sei deployment.

In 24 deployment point su quattro continenti e 22 nodi sottostanti, sono stati trovati dati residui in 18 e 20 nodi rispettivamente. I tipi di blocchi recuperati includevano directory structure, pagine database e SQLite database completi. Cloudflare ha chiarito che gli attaccanti non possono scegliere vittima o host, non possono leggere dischi connessi e non possono garantire la presenza di dati residui. L'esposizione dipende dalla posizione del workload e da quali blocchi dm-thin ha reallocato. I ricercatori non hanno dimostrato la modifica di dati altrui né impatto sulla disponibilità. La discussione su LinkedIn si è concentrata sui meccanismi di isolamento. Peter Ward di Visa ha suggerito controlli espliciti di azzeramento all'allocazione o rilascio, trattando i dati residui come controllo primario di isolamento. Sherin Shahanas ha osservato che l'isolamento è spesso solo un termine architetturale senza test allo strato di storage. Il problema è emerso tra il rilascio di Azure Container Apps Sandboxes, che usa microVM hardware-isolate, e i benchmark di snapshot GKE con gVisor, entrambi mirati a carichi di lavoro di agenti intelligenti. Cloudflare ha risposto rapidamente: la segnalazione è arrivata il 4 settembre alle 15:26 UTC, è stato creato un ticket alle 18:45, il fix runtime è stato merge alle 21:27, le modifiche per pool e risorse online sono state merge alle 22:03 e il deployment è iniziato alle 23:15, completandosi il 7 settembre.