veilletech.fr
25 sept. Feed du jour
#05 CLOUDFLARE Article

Cloudflare : un disque neuf, les données d'un autre

Supprimer ne suffit pas : il faut aussi effacer.

Signalée le 4 septembre par Oren Yomtov (Accomplish), une faille de Cloudflare Containers laissait un client relire des blocs de disque libérés par d'autres : le pool dm-thin ne remettait pas à zéro les blocs réattribués. Cloudflare a corrigé toute la flotte et ne voit aucune exploitation ; la leçon vaut pour quiconque partage des volumes thin entre locataires.

3 min de lectureintermédiairevidéo 1:22
Partager
Sommaire6 sections
  1. Ce qui se passe
  2. Le mécanisme
  3. Ce qui a été vu
  4. Une correction en deux temps
  5. Ce que ça change chez vous
  6. À retenir

Ce qui se passe

Cloudflare a publié le 24 septembre le compte rendu d'une faille de Cloudflare Containers, et donc de Sandboxes, qui repose dessus. Un client disposant d'un compte Workers Paid pouvait relire des données laissées sur disque par les conteneurs d'autres clients passés sur le même hôte. Oren Yomtov, de la société Accomplish, l'a signalée le 4 septembre via HackerOne. Toute la flotte est corrigée, sans action de la part des clients.

Le mécanisme

Chaque conteneur tourne dans sa propre VM Firecracker et reçoit un disque racine inscriptible, /dev/vdc, fourni par dm-thin, le provisionnement fin du device mapper de Linux. dm-thin n'alloue un bloc physique qu'à la première écriture dans une zone. Les blocs faisaient 64 Kio, et un volume supprimé rendait les siens à un pool partagé entre clients.

Ce pool portait l'option skip_block_zeroing : un bloc n'était pas remis à zéro avant d'être confié à un nouveau disque. La preuve de concept :

  1. créer un conteneur, ouvrir /dev/vdc et en lire une référence ;
  2. écrire 4 Kio alignés dans chaque zone de 64 Kio qui correspond à de l'espace libre ext4 ;
  3. relire ces blocs : les 60 Kio non écrits contiennent ce qu'y avait laissé l'occupant précédent.

Lire une zone jamais écrite ne donnait rien, dm-thin répondant par des zéros sans rien allouer. C'est la petite écriture qui déclenchait l'allocation.

Ce qui a été vu

Pour distinguer leurs blocs de ceux des autres, les chercheurs se sont appuyés sur les sommes de contrôle des répertoires ext4 (metadata_csum). Sur six placements : 5 614 blocs de répertoires testables, aucun issu de leur propre système de fichiers, 2 700 inodes de répertoires étrangers. Au total, des résidus sur 18 placements sur 24 et 20 nœuds sur 22, sur quatre continents : structures de répertoires, pages de bases de données, bases SQLite complètes. Leurs scripts ne produisaient que des comptages, et les données récupérées ont été supprimées.

Les limites sont réelles : impossible de viser une victime ou de lire un disque encore attaché, et aucune modification de données n'a été démontrée. Cloudflare a appliqué des signatures de détection à la télémétrie d'E/S disque conservée et n'y trouve que les chercheurs et ses propres équipes.

Une correction en deux temps

Ce que ça change chez vous

Si vous hébergez plusieurs locataires sur des volumes thin, vérifiez que la mise à zéro n'a pas été coupée pour gagner en performance :

Terminal
# Toute ligne de pool thin qui porte cette option est concernée
sudo dmsetup table | grep skip_block_zeroing

Avec LVM, c'est le réglage thin_pool_zero de lvm.conf, actif par défaut, et lvchange --zero y le rétablit sur un pool existant. Comme chez Cloudflare, réactiver la mise à zéro ne nettoie pas ce qui est déjà alloué.

Source : How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers, Cloudflare, 24 septembre 2026.