Cloudflare a révélé les résultats d’une réévaluation des attaques Spectre à distance contre la plateforme Cloudflare Workers, menée au cours de l’année 2024 et au début de 2025. L’équipe de recherche est parvenue à construire une preuve de concept fonctionnelle dans l’environnement de production et à exfiltrer des données d’un Worker victime vers un Worker attaquant contrôlé par les chercheurs, à un débit pouvant atteindre 12 bits par seconde et avec une précision supérieure à 99 %.
L’entreprise confirme que l’attaque présentée a été traitée dans le système de production grâce aux mesures prises par l’équipe Cloudflare Workers Runtime, et qu’elle n’a trouvé aucun indice d’exploitation active au cours des trois dernières années. Les résultats ont été publiés dans un article cosigné par Albert Pedersen, Haocheng Xiao, Sam Ainsworth, Nigel Topham et Martin Schwarzl.
Pourquoi cette recherche est-elle importante ?
Workers repose sur l’exécution de JavaScript non fiable en périphérie, des dizaines de milliers de locataires pouvant partager un même processus du système d’exploitation au moyen d’isolats V8. Chaque Worker dispose d’un tas JavaScript distinct, ce qui améliore le temps de démarrage et l’efficacité de l’hébergement d’un grand nombre de locataires, mais signifie également qu’une vulnérabilité de lecture arbitraire au sein du processus pourrait ouvrir la voie à une fuite de données entre locataires.
Les attaques Spectre exploitent l’exécution spéculative des processeurs. Lorsqu’un processeur prédit le résultat d’une branche logicielle et exécute des instructions avant de l’avoir confirmé, les résultats peuvent ensuite être annulés, mais des traces subtiles subsistent dans l’état microarchitectural du processeur, notamment dans le cache. L’attaquant peut exploiter les différences de temps d’accès à la mémoire pour déduire des bits de données qu’il n’est pas censé pouvoir lire.
Cloudflare avait lancé en 2021 une défense de production appelée Dynamic Process Isolation, ou DyPrIs, afin d’isoler les scripts qui semblent malveillants dans des processus distincts. La réévaluation a toutefois découvert une limite du mécanisme d’exécution qui permettait à l’attaque de rester active suffisamment longtemps pour contourner l’isolation.
Comment l’attaque a-t-elle contourné les limites de Workers ?
La plateforme limite les temporisateurs locaux et n’autorise ni la mémoire partagée ni le multithreading ; les méthodes de mesure traditionnelles fondées sur SharedArrayBuffer ne sont donc pas disponibles. À la place, les chercheurs ont utilisé un temporisateur distant via une connexion WebSocket et ont tiré parti de l’amplification du signal produite par les événements du cache grâce à la politique de remplacement tree-based PLRU du cache L1.
L’équipe a également conçu deux types de Spectre gadgets. Le premier a servi à exfiltrer des pointeurs compressés du tas, notamment l’adresse de base du tas propre à l’isolat. Le second reposait sur une confusion spéculative de type pour accéder à un pointeur brut de 64 bits, ce qui a permis de transformer la fuite en lecture à partir d’une adresse choisie par l’attaquant. Au moment de la recherche, V8 Sandbox n’était pas encore déployé dans Workers, et TypedArray faisait partie des structures qui conservaient un pointeur brut vers leur stockage sous-jacent.
Pour garantir des mesures reproductibles, les chercheurs ont créé de grands ensembles d’objets dépassant la capacité du cache, puis ont sélectionné des emplacements aléatoires à chaque tour au lieu de rechercher un ensemble d’éviction précis pour chaque ligne de cache. Des Durable Objects ont également été utilisés pour maintenir un contexte d’exécution de longue durée, tandis que les messages WebSocket permettaient de réinitialiser les limites de temps de traitement et de requêtes. En utilisant des pauses périodiques entre les lots d’exécution, il a été possible de maintenir l’isolat actif de cinq heures à plus de 20 heures.
Pour obtenir la proximité entre l’attaquant et la victime, le Worker attaquant appelait le Worker victime via fetch, ce qui entraînait dans la plupart des cas leur exécution dans le même processus sur le même serveur périphérique. Cette méthode permettait également de tirer parti des périodes de faible charge dans les centres périphériques afin d’accroître la stabilité des mesures.
Qu’est-ce qui a changé concrètement dans les défenses de Cloudflare ?
Cloudflare a introduit plusieurs modifications au lieu de s’appuyer sur une seule mesure. V8 Sandbox fait désormais partie des couches de protection et vise à réduire la présence de pointeurs bruts de 64 bits dans de grandes parties du tas JavaScript. Cela rend certains des outils de confusion spéculative utilisés dans la recherche plus difficiles à réutiliser, mais ne constitue pas un remède complet contre les attaques Spectre, car d’autres outils ou formes permettant d’obtenir un accès hors des limites de la mémoire pourraient apparaître.
En septembre 2025, l’entreprise a déployé une isolation intra-processus fondée sur les Memory Protection Keys, ou MPK. Cette technologie divise la mémoire en domaines de protection et en modifie les droits d’accès à faible coût, de sorte que le tas de chaque isolat se trouve derrière une barrière imposée par le matériel. Cela empêche la lecture directe entre les tas des isolats dont dépendait l’attaque, mais n’élimine pas tous les risques liés à Spectre ; le nombre de domaines de protection est limité et le système exige une gestion précise de l’état des clés de protection.
Cloudflare a également amélioré le mécanisme DyPrIs afin de gérer les opérations de longue durée et les charges d’E/S intensives. Attendre la fin de l’appel pour isoler le script ne suffit pas lorsqu’une connexion WebSocket ou un Durable Object peut maintenir l’appel ouvert pendant des heures. L’entreprise étudie également l’ajout du comportement de temporisation distante aux signaux de détection, notamment lorsque des opérations similaires à des temporisateurs sont répétées autour de sections à forte intensité de calcul, au lieu de considérer le trafic réseau associé comme un bruit ordinaire.
Limites du résultat
Le test a été effectué contre des Workers contrôlés par Cloudflare et les chercheurs, et ne constitue pas une preuve de compromission de locataires réels. En outre, le débit d’exfiltration le plus élevé a été obtenu au détriment de la précision, selon les précisions de l’entreprise, et aucun indice d’exploitation réelle n’a été détecté au cours des trois années précédentes. Les résultats révèlent donc une capacité offensive exploitable dans le modèle d’isolation précédent, ainsi que l’importance de combiner l’isolation des processus, la protection de la mémoire imposée par le matériel et la détection comportementale continue.