Spectre buca Cloudflare Workers: JWT sottratto tra tenant a 12 bit al secondo

🛡️ Executive Summary

• Ricercatori dimostrano un attacco Spectre remoto contro Cloudflare Workers capace di sottrarre un JWT da un Worker co-locato senza exploit V8.
• Il leak raggiunge 12 bit al secondo con accuratezza del 99,16%, sfruttando WebSocket come timer remoto e limiti di Dynamic Process Isolation.
• Cloudflare ha mitigato l’attacco rafforzando DyPrIs e introducendo V8 Sandbox e isolamento hardware basato su Memory Protection Keys.

Un attacco Spectre completamente remoto è riuscito a estrarre un JSON Web Token da un Cloudflare Worker appartenente a un tenant differente, dimostrando che anche un ambiente serverless progettato specificamente per limitare i side-channel può essere colpito sfruttando effetti microarchitetturali della CPU. I ricercatori hanno raggiunto una velocità massima di 12 bit al secondo con accuratezza del 99,16%, circa 360 volte superiore alla precedente dimostrazione del 2021. L’esperimento è stato condotto direttamente nell’ambiente di produzione di Cloudflare Workers, utilizzando però esclusivamente Worker controllati dal team di ricerca: nessun dato dei clienti è stato sottratto. Cloudflare ha già modificato l’infrastruttura introducendo nuove difese hardware e software.

Spectre attraversa l’isolamento tra due Cloudflare Workers

Il lavoro, descritto nello studio Remote-Timer-as-a-Service pubblicato dai ricercatori, prende di mira una caratteristica fondamentale dell’architettura di Cloudflare Workers. Per ridurre tempi di avvio e consumo di risorse, la piattaforma non assegna necessariamente un processo del sistema operativo distinto a ogni tenant. Molti Worker possono invece essere eseguiti nello stesso processo attraverso V8 isolates, ambienti JavaScript separati logicamente dal motore di Google. Questa scelta consente a Cloudflare di eseguire migliaia di applicazioni sullo stesso server con un overhead molto inferiore a quello richiesto da container o processi completamente separati. Il problema nasce però a livello microarchitetturale: Spectre non deve necessariamente violare direttamente i controlli software di V8. L’attaccante induce il processore a effettuare operazioni speculative su dati ai quali il codice non dovrebbe avere accesso e ricostruisce successivamente il risultato osservando gli effetti collaterali lasciati nella microarchitettura. È lo stesso principio che rende particolarmente delicati gli ambienti cloud multi-tenant, come dimostrato anche da VMScape e dagli attacchi Spectre capaci di attraversare i confini tra guest e host sui processori AMD.

Cloudflare aveva eliminato i timer locali proprio per fermare Spectre

Cloudflare aveva progettato Workers tenendo conto di questo rischio fin dalle prime versioni. Nella documentazione ufficiale sul modello di sicurezza di Workers l’azienda spiega che un Worker non dispone di normali timer ad alta precisione durante l’esecuzione. Date.now() rimane congelato mentre il codice usa CPU, non vengono offerte API equivalenti ai timer ad alta risoluzione e il runtime non espone multithreading o memoria condivisa che possano essere utilizzati per costruire strumenti di misurazione alternativi.

La logica è importante perché un side-channel Spectre ha bisogno di distinguere variazioni temporali estremamente piccole per comprendere se un determinato dato abbia modificato cache o altre strutture della CPU. I ricercatori hanno però dimostrato che il divieto dei timer locali non elimina necessariamente la possibilità di misurare il tempo: basta spostare il cronometro fuori dal Worker bersaglio.

WebSocket diventa un timer remoto ad alta precisione

La tecnica viene definita Remote-Timer-as-a-Service. Il Worker dell’attaccante comunica con un sistema remoto attraverso WebSocket e utilizza il tempo necessario alle risposte come sorgente di misurazione. Il rumore della rete renderebbe normalmente impossibile distinguere variazioni microarchitetturali minuscole, ma i ricercatori utilizzano tecniche di amplificazione che ripetono l’effetto molte volte prima di effettuare la misura. Una differenza che sarebbe troppo piccola per essere rilevata direttamente diventa così abbastanza grande da emergere anche attraverso un timer remoto. L’esperimento dimostra quindi un concetto particolarmente rilevante per i sistemi serverless: rimuovere un’API temporale dal sandbox non garantisce l’assenza di un timer se il codice può comunicare con risorse esterne. Il risultato è ancora più significativo perché l’attacco non richiede esecuzione di codice nativo, una vulnerabilità software di V8 o una vera sandbox escape. Il codice dell’aggressore rimane all’interno del proprio isolate e sfrutta esclusivamente il comportamento speculativo del processore.

Un JWT viene estratto a 12 bit al secondo

Per dimostrare concretamente l’impatto, i ricercatori hanno collocato intenzionalmente un JWT segreto nella memoria di un Worker vittima controllato dal team e hanno eseguito l’attacco da un secondo Worker co-locato nello stesso processo. Nei test sui server di produzione Cloudflare basati su processori AMD EPYC Zen 2 e Zen 3, il canale ha raggiunto fino a 12 bit al secondo con un’accuratezza del 99,16%. La precedente ricerca del 2021 aveva ottenuto circa 2 bit al minuto, equivalente a 120 bit all’ora. Il salto prestazionale è quindi di diversi ordini di grandezza e rende il recupero di token, chiavi o altri piccoli segreti molto più realistico.

Il team ha effettuato parte delle misurazioni durante le ore notturne, quando l’utilizzo delle CPU era compreso tra 10% e 25%, ottenendo le condizioni migliori. Un maggiore carico sul server riduce la velocità del side-channel, ma secondo lo studio non elimina completamente la fattibilità dell’attacco. La dinamica richiama altri scenari nei quali lo stato microarchitetturale rompe assunzioni di isolamento considerate solide, come GPUBreach e il side-channel capace di attraversare i confini tra memoria GPU e host.

Dynamic Process Isolation non reagiva abbastanza velocemente

Cloudflare aveva già sviluppato una contromisura specifica denominata Dynamic Process Isolation, DyPrIs. Il sistema monitora il comportamento dei Worker e, quando identifica segnali compatibili con un side-channel, sposta il codice sospetto in un processo separato. Il problema scoperto dai ricercatori riguarda sia quando viene applicato l’isolamento sia come viene rilevato l’attacco. Un Durable Object può mantenere la stessa invocazione attiva per periodi compresi tra cinque e oltre venti ore, permettendo al codice dell’attaccante di continuare a operare prima che il processo venga separato. Inoltre l’intenso traffico WebSocket genera attività I/O capace di influenzare il segnale microarchitetturale usato da DyPrIs. In particolare, l’aumento dell’attività dell’instruction Translation Lookaside Buffer riduceva il valore normalizzato delle branch misprediction fino a portarlo sotto la soglia di rilevamento. I ricercatori sostengono quindi che una difesa di questo tipo dovrebbe essere capace di reagire durante l’esecuzione e utilizzare segnali difficili da mascherare attraverso l’attività del Worker.

Cloudflare introduce V8 Sandbox e protezione hardware MPK

Dopo la disclosure coordinata, Cloudflare ha modificato il modello di isolamento. Nella descrizione delle nuove difese applicate a Workers l’azienda indica tre livelli principali: DyPrIs migliorato, V8 Sandbox e Memory Protection Keys. Il V8 Sandbox restringe l’accesso speculativo ai puntatori a 64 bit, riducendo la superficie che un isolate può utilizzare per raggiungere dati esterni al proprio spazio. Le MPK, disponibili sui processori x86 moderni, permettono invece di associare regioni di memoria a chiavi hardware e controllarne l’accesso senza il costo di un cambio completo di processo. Cloudflare utilizza queste chiavi insieme a un layout della memoria che viene ruotato per impedire che due sandbox vicine finiscano protette dalla stessa chiave. La soluzione mira a conservare parte del vantaggio prestazionale del modello a isolate pur aggiungendo una separazione più vicina all’hardware. L’intervento arriva mentre il runtime Workers era già stato rafforzato dopo altre vulnerabilità capaci di mettere a rischio isolamento e sandbox di workerd.

Nessuna evidenza di sfruttamento contro clienti Cloudflare

Il punto più importante riguarda l’impatto effettivo. L’esperimento non ha sottratto informazioni appartenenti ai clienti Cloudflare: sia il Worker attaccante sia quello vittima erano controllati dai ricercatori e il JWT era stato inserito intenzionalmente per verificare il canale di fuga. Cloudflare afferma inoltre di non avere individuato indicatori di sfruttamento reale negli ultimi tre anni. La ricerca dimostra quindi un percorso tecnicamente praticabile, non una violazione già avvenuta su larga scala. Per gli utenti di Cloudflare Workers non è prevista una patch da installare autonomamente, perché le mitigazioni sono state applicate nell’infrastruttura gestita dal provider. Il valore del lavoro è soprattutto architetturale: Spectre continua a dimostrare che l’isolamento software non coincide necessariamente con l’isolamento microarchitetturale. Nei servizi serverless che condividono processi, CPU e memoria tra migliaia di tenant, anche un Worker perfettamente confinato dal linguaggio può osservare effetti prodotti da risorse hardware condivise. La risposta di Cloudflare mostra quindi una tendenza destinata a diventare sempre più importante nel cloud: l’isolamento efficiente non può dipendere da un solo livello, ma deve combinare sandbox software, rilevamento comportamentale e protezioni implementate direttamente dal processore.