Fuite mémoire « Cloudbleed » de Cloudflare
Un bug de dépassement de tampon dans les serveurs périphériques de Cloudflare les amenait à divulguer des fragments de mémoire adjacente — mots de passe, cookies et messages privés d'autres clients — dans des pages web, dont certains ont été mis en cache par les moteurs de recherche. La faille est restée active pendant des mois avant d'être découverte par Project Zero de Google.
- Victime
- Cloudflare, Inc.
En février 2017, le chercheur en sécurité Tavis Ormandy, de Project Zero de Google, a découvert que Cloudflare — le réseau de diffusion de contenu et de proxy inverse placé devant des millions de sites web — divulguait des fragments aléatoires de la mémoire de ses propres serveurs dans des pages web. Ces fragments pouvaient contenir tout ce qui avait récemment transité par la périphérie de Cloudflare : mots de passe, cookies de session, jetons d'authentification, corps de requêtes HTTP POST et messages privés appartenant à des clients totalement étrangers les uns aux autres. Comme certaines des pages fuyant ces données étaient mises en cache par les moteurs de recherche, des données sensibles sont restées exposées dans des caches publics bien après la correction du bug lui-même. La faille a été baptisée « Cloudbleed », en écho à la vulnérabilité Heartbleed de 2014.
Ce qui s'est passé
Les serveurs périphériques de Cloudflare exécutaient un analyseur HTML qui réécrivait les pages à la volée — pour masquer les adresses électroniques, appliquer les Server-Side Excludes et réécrire automatiquement les liens HTTP en HTTPS. Un subtil bug de dépassement de tampon dans ce code d'analyse faisait que, lorsque le code HTML d'une page était malformé d'une certaine manière, l'analyseur dépassait la fin d'un tampon et émettait la mémoire non initialisée adjacente dans la réponse renvoyée aux visiteurs.
Cette mémoire divulguée n'était pas du bruit aléatoire — c'étaient des données en direct provenant d'autres requêtes transitant par les mêmes serveurs Cloudflare. Un visiteur d'un site pouvait, par hasard, recevoir un fragment du mot de passe ou du message privé d'une autre personne intégré dans la page qu'il chargeait.
Ampleur et exposition
- Le bug a pu divulguer de la mémoire dès le 22 septembre 2016, mais la période d'impact maximal s'est étendue d'environ le 13 au 18 février 2017, lorsqu'une fonctionnalité nouvellement déployée a fortement augmenté le taux de fuite.
- Au pic, environ 1 requête HTTP sur 3,3 millions transitant par Cloudflare risquait de divulguer de la mémoire — un faible ratio, mais qui, rapporté à l'énorme volume de trafic de Cloudflare, signifiait que le bug s'est déclenché des millions de fois.
- Les données divulguées couvraient une vaste base de clients : Cloudflare protégeait des millions de domaines, de sorte qu'un seul bug exposait simultanément des fragments provenant de tout le web.
- Le risque le plus aigu provenait des caches des moteurs de recherche, où les données divulguées avaient été indexées et stockées. Cloudflare a collaboré avec Google, Bing, Yahoo et d'autres pour purger les pages mises en cache.
Réaction
Ormandy a signalé le bug à Cloudflare le 17 février 2017. L'équipe de Cloudflare a désactivé les trois fonctionnalités fautives en quelques heures après réception du signalement, les a globalement coupées dès le lendemain et a déployé un correctif permanent en quelques jours. L'entreprise a publié un rapport d'incident public détaillé le 23 février. Les enquêteurs n'ont trouvé aucune preuve que des attaquants aient découvert ou exploité le bug avant qu'il ne soit signalé.
Pourquoi c'est important
Cloudbleed est l'exemple type de la manière dont un seul bug de sécurité mémoire dans une infrastructure partagée peut avoir un rayon d'impact démesuré. Parce que les proxys de Cloudflare traitent le trafic de millions de sites sans rapport entre eux, une faille affectant un seul chemin de code divulguait des données indistinctement à travers tous ces sites — et l'implication de la mise en cache par les moteurs de recherche a étendu le nettoyage bien au-delà du simple correctif des serveurs d'origine. L'incident a renforcé deux leçons : que le code d'analyse non sûr en mémoire reste un risque critique dans les systèmes à haut débit, et que la centralisation du web derrière une poignée de fournisseurs périphériques concentre le risque autant que les bénéfices. Il est fréquemment cité aux côtés de Heartbleed comme argument en faveur des langages à sécurité mémoire pour les analyseurs sensibles à la sécurité.
Chronologie
Le bug de dépassement de tampon devient potentiellement exploitable — la date la plus ancienne à partir de laquelle les serveurs périphériques de Cloudflare ont pu divulguer de la mémoire.
Une nouvelle fonctionnalité (Automatic HTTP Rewrites) utilisant l'analyseur cf-html augmente fortement le taux de fuite mémoire ; la période d'impact maximal commence.
Tavis Ormandy, de Project Zero de Google, remarque des données sensibles corrompues dans des réponses web lors d'un fuzzing, les relie à Cloudflare et les signale. Cloudflare désactive les fonctionnalités concernées en quelques heures.
Cloudflare désactive globalement les trois fonctionnalités responsables (obfuscation des courriels, Server-Side Excludes, Automatic HTTPS Rewrites) ; la période de fuite maximale prend fin.
Cloudflare publie son rapport d'incident public, donnant au bug son surnom de « Cloudbleed ».
Cloudflare et les moteurs de recherche achèvent un balayage pour purger les données mises en cache divulguées ; les enquêteurs ne relèvent aucune preuve d'exploitation malveillante.
Sources
- blog.cloudflare.comhttps://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
- en.wikipedia.orghttps://en.wikipedia.org/wiki/Cloudbleed
- bugs.chromium.orghttps://bugs.chromium.org/p/project-zero/issues/detail?id=1139
- rapid7.comhttps://www.rapid7.com/blog/post/2017/02/24/cloudflare-data-leakage-or-dare-i-saycloudbleed/