L'étude révèle la variante distante de Spectre qui filtre un JWT dans la mémoire Cloudflare Worker

Les chercheurs en sécurité ont publié une expérience contrôlée qui démontre une variante distante de Spectre capable de filtrer un JSON Web Token (JWT) hébergé dans la mémoire d'un autre Cloudflare Worker co- situé dans le même processus, avec un taux d'exfiltration maximum jusqu'à 12 bits par seconde. Dans le test de bout en bout, les auteurs ont exécuté un travailleur attaquant et un travailleur « victime » sous leur contrôle et ont délibérément placé le JWT dans la mémoire du second pour mesurer le canal. Cloudflare a confirmé que l'expérience n'avait pas accès aux données des clients et qu'elle avait déjà déployé des mesures d'atténuation de la production; la société a également déclaré qu'elle n'avait pas trouvé d'indicateurs d'exploitation actifs au cours des trois dernières années.

Faits : la technique est basée sur une version de la soi-disant "exécution de transit" ou attaques Spectre, où les lectures spéculatives et microarchitecturales deviennent des canaux latéraux du temps pour filtrer les bits d'une autre exécution. Dans les environs de Cloudflare Workers cela n'est possible que si l'agresseur et la victime finissent par co-localiser dans différents isolats V8 dans le même procédé. Le travail des chercheurs décrit deux facteurs clés qui ont facilité l'évasion : premièrement, qu'un canal de synchronisation à distance était possible à l'aide de WebSockets (les travailleurs n'exposent pas les sources locales de synchronisation à haute résolution); deuxièmement, que les objets durables permettent à une île de rester active pendant des heures, empêchant la politique d'isolement dynamique (DyPrIs) de déplacer immédiatement le code vers un processus distinct.

Techniquement, l'attaque n'exige pas l'exécution de code natif ou une vulnérabilité V8 ou "évasion" du bac à sable: l'adversaire exécute le code légitime de son propre isolat et exploite les signaux microarchitecturaux (comme les états iTLB et les prédicteurs de branche) pour induire et mesurer les effets observables par une connexion à distance. Les chercheurs ont également documenté que les charges intensives I / O par WebSockets augmentent l'activité iTLB et réduisent le signal de détection utilisé par DyPrIs - l'heuristique Cloudflare pour décider quand déplacer un isolat suspect à un autre processus. Selon le journal, cette réduction du signal a permis à la détection de ne pas tirer pendant la fuite.

Confirmé par Cloudflare : Les travailleurs gèrent plusieurs locataires dans les isolats V8 dans le même processus dans le but de réduire la latence de départ, et leur défense DyPrIs déplace les isolats suspects à des processus séparés après une invocation. Après la divulgation, Cloudflare décrit avoir élargi DyPrIs, intégré la "V8 Sandbox" (accès transitoire limité aux pointeurs 64 bits) et déployé un schéma d'isolation basé sur les clés de protection de la mémoire (MPK) - une fonctionnalité CPU qui permet de protéger les régions de mémoire avec des clés matérielles - pour réduire la possibilité de lecture croisée entre des tas d'isolats.

Données reproductrices de l'étude : les expériences ont été réalisées sur des serveurs Linux avec des processeurs AMD EPIC Zen 2 et Zen 3 ; pour obtenir le taux d'exfiltration maximum, les auteurs ont travaillé sur des fenêtres à faible charge (10-25% CPU de nuit), et ont rapporté une précision de 99.16% en récupération bit au taux maximum. Les auteurs indiquent clairement qu'avec plus de charge du système, la vitesse diminue, mais la technique reste viable mais plus lente. Comparaison historique: la précédente attaque à distance contre les travailleurs, publiée en 2021 par Cloudflare et TU Graz, a atteint environ 120 bits par heure (~ 2 bits / minute); la nouvelle mesure représente une amélioration significative du taux (jusqu'à 360 fois plus rapide dans des conditions contrôlées).

Ce que cela signifie pour les utilisateurs des travailleurs et des services cloud: en termes pratiques, la technique montre que dans certaines conditions un acteur avec un code légitime déployé sur la même plate-forme peut - théoriquement - extraire des secrets stockés en mémoire d'autres locataires. Le test a fui un JWT, un type de secret qui peut permettre l'accès à l'API ou les validations de session si elle n'est pas limitée dans le temps. Bien que la capacité d'exfilter des dizaines de bits par seconde implique encore un processus relativement lent pour obtenir de longs secrets, l'automatisation et la répétition permettent de reconstruire des clés ou des jetons au fil du temps.

Ce qui est confirmé et ce qui reste incertain: il est confirmé que la technique fonctionne en laboratoire contre la configuration de production pré-patch, et que Cloudflare a déployé l'atténuation. Il n'est pas confirmé qu'il y ait eu exploitation chez les clients réels; Cloudflare ne signale aucun indicateur au cours des trois dernières années. On ne sait pas dans quelle mesure les mesures d'atténuation (combinaison améliorée de DyPrI, V8 Sandbox et MPK) éliminent toute l'exploitation pratique dans tous les scénarios et architectures, et l'impact de la performance ou de la compatibilité sur l'échelle.

Conséquences réelles possibles : pour les charges qui gardent longtemps les travailleurs en mémoire (par exemple les objets durables avec une longue invocation) ou qui utilisent intensive WebSockets, il y a un risque plus élevé de co-implantation exploitable. Les secrets à long terme sauvegardés dans la mémoire des travailleurs (clé API, JWT avec TTL complet, identifiants variables globaux) sont les actifs les plus vulnérables. Pour les environnements multi-tenus où la co-implantation est fréquente, ce type de canal met en évidence la tension entre l'optimisation de la latence et l'isolation puriste du processus.

Recommandations spécifiques pour les développeurs et les administrateurs: D'abord, traitez les secrets comme des secrets à court terme : réduisez les jetons TTL, souvent critiques, et appliquez des limites de portée. Évitez de garder des secrets sensibles dans les variables globales chez les travailleurs; utilisez des fixations de secrets gérés et des services externes avec des vérifications supplémentaires (p. ex. OAuth avec des mises à jour contrôlées). Pour les architectures qui utilisent des objets durables ou des connexions WebSocket, envisagez de réduire le temps de vie de longue invocation ou de fragmentation pour minimiser les surfaces dans la mémoire. Activez et examinez les politiques de votre fournisseur et la connexion pour détecter co- endroits inhabituels ou de longs modèles WebSocket. Si vous manipulez des données très sensibles, évaluez pour exiger l'exécution dans des environnements isolés ou des instances dédiées.

Recommandations pour les opérateurs de plate-forme: mettre en œuvre la détection en temps réel pendant l'exécution (pas seulement après l'invocation), et utiliser des signaux qui ne peuvent pas être facilement amortis par l'activité I / O. Combiner des protections matérielles comme MPK avec le bac à sable V8 et la disposition de la mémoire rotative réduit la probabilité que deux isolats partagent la même clé de protection, mais ces mesures devraient être évaluées par rapport aux charges réelles et aux architectures CPU multiples. Maintenir des vérifications proactives et des recherches de modèles de chronométrage à distance en utilisant WebSockets comme canal et limiter l'exposition des connexions persistantes lorsque ce n'est pas nécessaire.

Sources et lecture supplémentaire: explication technique originale de Spectre https: / / spectreatack.com / spectre.pdf, et la documentation des travailleurs Cloudflare pour comprendre le modèle opérationnel des isolats et des objets durables https: / / développé. Pour plus de détails sur les clés de protection de la mémoire dans CPU x86, voir le guide Intel sur MPK https: / / www.intel.com / content / www / us / fr / developed / articles / technique / memory-protection-keys.html.

Bref, la recherche rouvre la discussion sur l'innocuité de l'isolement linguistique (isolats V8) dans le même processus pour optimiser la latence. Les mesures d'atténuation déployées par Cloudflare réduisent la surface d'attaque, mais la responsabilité partagée incombe aussi aux développeurs et aux opérateurs : minimiser les durées de vie secrètes, éviter les longs schémas d'exploitation en mémoire et vérifier l'utilisation intensive de WebSockets sont des étapes pratiques qui limitent l'exposition tout en continuant à évaluer l'efficacité des protections sur une échelle.