Corrections Cloudflare Défaillance des conteneurs permettant de lire les données résiduelles sur les disques partagés

Cloudflare a corrigé une vulnérabilité dans son service Containers qui a permis à un client autorisé de lire les données résiduelles laissées par les conteneurs d'autres clients sur des disques partagés, selon l'entreprise et les chercheurs qui ont signalé l'échec. Le problème n'impliquait pas l'accès aux processus continus des autres clients ou la capacité de choisir qui appartenait aux renseignements récupérés., mais il a laissé des blocs de stockage avec des restes de fichiers - répertoires, pages de base de données et bases SQLite complètes, selon le nombre - qu'un attaquant avec accès au conteneur a pu extraire.

Faits confirmés : le chercheur Oren Yomtov, de l'entreprise Accomplish, a signalé l'échec de Cloudflare le 4 septembre ; la cause technique était la reconfiguration des disques en mode « mince provisionnement » (capacité générale d'attribution en blocs de 64 KB) de sorte qu'en retournant les blocs dans le pool partagé, le système ne les a pas nettoyés avant de les réaffecter ; Cloudflare a réactivé la suppression des nouveaux blocs et a enlevé / recyclé les unités en production, complétant le nettoyage le 19 septembre et révélant l'incident cinq jours plus tard. Les enquêteurs ont vérifié le timbre le 14 septembre et confirmé que leur test conceptuel avait cessé de fonctionner.

Techniquement (explanation): les disques assignés aux conteneurs sont créés par un dispositif de type mince, qui attribue de l'espace en blocs de 64 KB. Lorsqu'un conteneur est détruit, ses blocs sont retournés à la piscine générale. En raison d'une configuration qui a omis le nettoyage (largeur / zéro) lors de la réaffectation des blocs, le prochain conteneur qui a reçu ce bloc ne pouvait écrire que 4 KB dans le 64 KB, puis lire le bloc à un niveau brut; le reste des 60 KB est resté avec les octets du locataire précédent. Les chercheurs ont exploité exactement cela : ils ont écrit un petit fragment et ont lu le bloc entier du niveau brut du bloc pour récupérer les données résiduelles. Ce vecteur attaque la réutilisation dangereuse des blocs, et non la mémoire chaude et l'intégrité des processus d'exécution.

Quels systèmes et quels clients ont été touchés: Conteneurs Cloudflare et son produit Boîtes à sable Cloudflare(une couche conçue pour exécuter un code peu fiable, y compris les agents IA) a été identifiée comme étant affectée. Les chercheurs ont également noté que la même configuration de disque a affecté le produit Browser Run, bien que Cloudflare n'ait nommé que Conteneurs et Sandboxes dans sa sortie. Cloudflare contrôle la répartition physique des serveurs et des disques, de sorte que l'exposition est venue du côté du fournisseur et non du choix du client.

Portée observée par les chercheurs et par Cloudflare : dans les tests de production contrôlés, les chercheurs ont récupéré du matériel résiduel dans 18 des 24 tentatives sur des serveurs choisis par Cloudflare, et dans 20 des 22 machines physiques distribuées sur quatre continents ; les restes inclus répertoires, profils de navigateur (Chromium), fichiers .env, fichiers d'identification et bases SQLite, selon le rapport des chercheurs et la confirmation partielle de Cloudflare. Cloudflare dit que ses enquêtes internes - basées sur les signatures créées à partir du test de concept - n'ont trouvé que l'activité autorisée (celle des chercheurs et de leur propre personnel) dans les dossiers conservés.

Ce qui est confirmé et ce qui est encore incertain : il est confirmé qu'il y avait une exposition résiduelle aux données dans les blocs de disques réaffectés et que Cloudflare a appliqué deux correctifs (réactiver la suppression en attribuant de nouveaux blocs et en remplaçant/déployant les disques et caches en production). C'est une estimation raisonnable - bien que non mathématiquement prouvée publiquement - que les restes pourraient contenir des secrets utiles (des jetons, des clés, des lettres d'identité) comme .env et des bases de données apparaissaient. L'incertitude est la fenêtre d'exposition totale: Cloudflare n'a pas précisé depuis quand la configuration dangereuse était active ou pendant combien de temps en termes absolus, de sorte qu'il ne peut pas être déterminé avec certitude combien de clients étaient potentiellement exposés ou pour quelle période exacte.

Risques réels pour les clients et conséquences pratiques: les informations récupérées peuvent inclure des identifiants, des jetons API, des secrets de configuration ou des parties de bases de données qui permettent des attaques subséquentes (réutilisation des identifiants, escalade hors environnement, accès aux services connectés). Bien qu'il n'y ait aucune preuve publique d'abus de tiers, la combinaison de données partiellement récupérées et de mécanismes d'analyse automatisés peut faciliter la reconstruction des secrets. En outre, pour les organisations soumises à des exigences réglementaires ou de conformité, la simple possibilité d'exfiltration de données dans un environnement à plusieurs locataires peut nécessiter des notifications ou des examens internes.

Mesures spécifiques à prendre par les clients touchés ou à risque: d'abord, identifier s'il faut utiliser des conteneurs, des boîtes à sable ou des navigateurs Exécuter et quelles images ou conteneurs pourraient contenir des secrets sur disque ou en couches d'images. Alors, Rouler immédiatement tout titre qui aurait pu être dans ces conteneurs: jetons API, clés de base de données, secrets de fichiers .env et clés SSH. N'attendez pas la seule confirmation du fournisseur; la rotation proactive est une mesure de risque peu coûteuse. Révocer des jetons et régénérer des références dans des services connectés (banques de données, services cloud, APIs tiers) est la mesure la plus directe pour atténuer les abus possibles.

Autres actions techniques recommandées : arrêter de stocker des secrets dans le système de fichiers conteneurs persistant; utiliser des mécanismes de gestion secrète (par défaut) ou de gestion secrète qui injectent des valeurs dans le temps de fonctionnement sans les écrire sur disque; monter des secrets en mémoire (tmpfs) lorsque c'est possible; chiffrer les données sensibles au niveau de l'application avant de les écrire sur disque afin que l'exposition au bloc ne permette pas de lire les clés claires. Voir les bonnes pratiques en gestion secrète : Gestion des secrets de l'OWASP Feuille de chaleur.

Vérification et surveillance : examiner les registres et les activités inhabituelles dans les services qui utilisent les contenants touchés; rechercher l'accès des PI ou des modèles inattendus et mettre en place des alertes sur l'utilisation anormale des clés. Bien que Cloudflare ait signalé avoir exécuté une détection basée sur la signature, il convient d'appliquer sa propre détection d'anomalies dans les services critiques et de vérifier les images et les couches de conteneur à la recherche de secrets intégrés.

Contexte technique et références supplémentaires : ce problème est un exemple de la façon dont l'optimisation des performances et la configuration de stockage à faible niveau (disposition fine et mise en cache de couches) peuvent introduire des vecteurs de fuite de données dans des environnements multi-tenus. Pour comprendre le mécanisme de provisionnement Thin et ses risques techniques, consultez la documentation du noyau Linux sur la provisionnement Thin de périphérique Mapper: noyau. Pour des instructions pratiques sur la façon de gérer les secrets des conteneurs et de réduire ce type de risque, la documentation des bonnes pratiques des plates-formes et des orchestres est utile (p. ex., les pratiques Docker et Kubernetes et la gestion secrète).

Conclusion: Cloudflare a fermé la voie d'attaque détectée et a nettoyé les ressources en production, et pour l'instant il n'y a aucun signe public d'abus de masse. Cependant, la nature de l'échec - la lecture de données résiduelles sur les disques partagés - implique que tout client qui a gardé des secrets sur les images ou les disques de conteneur devrait faire pivoter les références et revoir les pratiques de gestion secrète. La leçon opérationnelle est claire : dans les environnements multi-locataires, la défense doit inclure à la fois les contrôles des fournisseurs et les pratiques de développement strictes pour ne pas laisser de secrets sur disque ou compter exclusivement sur la sécurité physique ou hyperspectrice.

Sources supplémentaires et lecture: la communication et le suivi du fournisseur sont disponibles sur le blog Cloudflare https: / / blog.cloud, et l'explication technique de la fourniture mince dans Linux se trouve dans la documentation officielle du noyau: https: / / www.kernel.org / doc / html / latest / admin-guide / device-mapper / slim-provalising. html.