
Dans cet article (4)
Analyse de Spectre dans Cloudflare Workers pour l’isolation serverless
Points clés
- Demandez aux fournisseurs serverless comment ils limitent les minuteurs, la concurrence et les risques liés au placement des locataires.
- Considérez Spectre comme un problème permanent de conception de l’isolation, et non comme un problème de navigateur résolu.
- Concevez tôt les environnements d’exécution avec des limites contre les canaux auxiliaires, avant que la compatibilité ne rende plus difficile la suppression d’API plus sûres.
La réévaluation de Cloudflare rappelle que les plateformes en périphérie ont besoin de conceptions d’isolation pensées pour les canaux auxiliaires à distance, pas de nostalgie.
La réévaluation de Cloudflare rappelle que les plateformes en périphérie ont besoin de conceptions d’isolation pensées pour les canaux auxiliaires à distance, et non pour la nostalgie.
Spectre est le fantôme de la sécurité qui refuse de rester au sous-sol. Des années après que tout le monde a promis d’arrêter de laisser l’exécution spéculative traîner comme un pistolet à clous chargé, Cloudflare est revenu poser une question utile et inconfortable : que se passe-t-il lorsque l’attaque est distante, multi-locataire et vise l’infrastructure Workers ? C’est important, car le serverless a appris aux développeurs à penser en abstractions : déployez une fonction, laissez la plateforme la planifier, puis passez à autre chose. Spectre ne se soucie pas de votre couche d’abstraction. Il vit sous l’API, là où les processeurs spéculent, où les caches murmurent, et où l’isolation devient moins un mur qu’une négociation très coûteuse.
Ce que Cloudflare a réexaminé Selon le blog de
Cloudflare, Martin Schwarzl et Albert Pedersen ont déclaré que Cloudflare avait réévalué les attaques Spectre à distance sur son infrastructure Workers en 2024 et 2025. L’article décrit de nouvelles primitives d’attaque, notamment des gadgets Spectre, des minuteurs distants, l’obtention d’une co-localisation, et des défenses qui renforcent encore Cloudflare Workers. Voilà la phrase importante cachée dans les buissons techniques : des minuteurs distants plus la co-localisation transforment un canal auxiliaire, qui ressemblait à un projet scientifique de l’ère des navigateurs, en problème de conception de plateforme. Cloudflare présente cela comme de la recherche et du durcissement, pas comme un avis de violation, ce qui est le bon endroit pour ce type de travail. Les meilleures histoires de sécurité sont celles où l’article effrayant devient une revue d’architecture avant que qui que ce soit doive envoyer aux clients un haïku de regret. Quelque part, un modèle de communiqué de presse disant « nous prenons la sécurité très au sérieux » reste inutilisé, et pour une fois, j’en suis reconnaissant. La leçon pour les développeurs n’est pas « paniquez à propos de Workers ». C’est que les plateformes multi-locataires doivent partir du principe que d’anciennes catégories d’exploits seront reconditionnées lorsque des chercheurs trouveront de nouveaux outils de mesure. Les acteurs malveillants n’aiment rien tant qu’une technique retraitée avec un nouveau chemin pour revenir dans le bâtiment.
Pourquoi les réflexes de l’ère des navigateurs ne suffisent pas La documentation
de Cloudflare Workers indique que le runtime a été conçu dès le départ avec les préoccupations liées aux canaux auxiliaires en tête, en particulier parce que Workers héberge de nombreux locataires sur une infrastructure partagée. La documentation précise que Workers est conçu pour rendre impossible au code de mesurer localement son propre temps d’exécution : Date.now() est figé pendant l’exécution du code, aucun autre minuteur n’est fourni, et Cloudflare ne donne aucun accès à la concurrence, comme le multi-threading. Ce n’est pas glamour, mais le fil dentaire non plus, et les deux évitent des douleurs coûteuses plus tard. La même documentation de Cloudflare Workers souligne un point qui devrait être imprimé sur une tasse pour les architectes de plateformes : ces choix ne peuvent pas être introduits rétroactivement dans des plateformes comme les navigateurs web, parce qu’ils suppriment des API dont dépendent les applications existantes. C’est pourquoi la sécurité serverless ne peut pas se résumer à « utilisez des isolates » puis considérer le travail terminé. Si votre runtime expose suffisamment de surface de minutage et de concurrence, votre récit d’isolation écrit peut-être des chèques que le cache de votre processeur encaissera avec plaisir. Pour les développeurs, c’est le rare cas où une API manquante est une fonctionnalité, et non la gestion produit qui abandonne avant le déjeuner. Un modèle de minuteur moins pratique peut faire partie de la frontière de sécurité. C’est un compromis architectural, et il est bien plus facile de le faire à la naissance de la plateforme qu’après que des millions d’applications ont construit un sanctuaire de dépendances autour d’horloges précises.
L’isolation est une affaire de coût Dans la recherche sur
l’isolation dynamique des processus menée par Cloudflare avec TU Graz, Kenton Varda a écrit qu’« il n’existe aucune défense complète connue contre Spectre », que les locataires soient isolés avec des isolates, des processus, des conteneurs ou des machines virtuelles. Le même article de Cloudflare indique que l’objectif pratique est d’utiliser de nombreux outils pour augmenter le coût d’une attaque Spectre jusqu’à la rendre irréalisable. Traduction : il n’existe pas de sort magique de confinement, seulement des couches, de la friction, et assez de contrariété pour rendre l’arc narratif de l’attaquant profondément peu gratifiant. Ce point est utile au-delà de Cloudflare. Les développeurs qui évaluent une plateforme edge ou serverless devraient demander ce que le runtime retire, ce qu’il mesure, ce qu’il partage, et comment il gère le placement des locataires. Si le récit d’isolation d’un fournisseur commence et se termine par une seule primitive, ce n’est pas un modèle, c’est une brochure avec un casque. C’est aussi pour cela que la réévaluation de Cloudflare est constructive. Réexaminer les attaques Spectre à distance signifie traiter la plateforme comme un système vivant plutôt que comme une vitrine de trophées de mitigations passées. La dette de sécurité n’est pas toujours du vieux code ; parfois, c’est une vieille hypothèse que personne n’a revalidée depuis que la dernière génération de processeurs a de nouveau rendu tout bizarre.
Ce que cela signifie concrètement pour vous
Pour les équipes applicatives qui utilisent des plateformes serverless, la conclusion pratique est de traiter les canaux auxiliaires microarchitecturaux comme un élément de la diligence raisonnable vis-à-vis des fournisseurs. Demandez si la plateforme limite le minutage haute résolution, restreint les primitives de concurrence, et conçoit l’isolation des locataires en tenant compte de la mesure à distance. Vous n’avez pas besoin de devenir chercheur en exécution spéculative pour poser des questions d’achat plus pointues, même si cela améliorera vos goûts en matière de cauchemars. Pour les concepteurs de plateformes, Cloudflare Workers est la leçon centrale : l’isolation doit être conçue avant que la compatibilité ne se calcifie. Une fois que les clients dépendent de minuteurs précis, de comportements d’exécution partagés ou de fonctionnalités de concurrence, les supprimer devient une crise de migration avec un logo. Le meilleur moment pour rendre les canaux auxiliaires ennuyeux était lors de la conception du runtime ; le deuxième meilleur moment est lors de la prochaine revue d’architecture. Ce qu’il faut surveiller ensuite, c’est si davantage de plateformes serverless et edge publient des recherches aussi précises sur les canaux auxiliaires à distance. Internet ne devient pas plus sûr parce que nous avons déclaré que Spectre appartenait au passé. Il devient plus sûr lorsque les plateformes rouvrent régulièrement le dossier, mettent à jour le modèle de menace, et rendent le coût de l’attaque supérieur au gain.