Wprowadzenie do problemu / definicja
Nowe badania nad bezpieczeństwem środowisk serverless pokazują, że ataki z rodziny Spectre nadal stanowią realne zagrożenie dla architektur wielodzierżawnych. W opisanym scenariuszu badacze wykazali możliwość zdalnego odczytu fragmentów pamięci z sąsiedniego Workera działającego w tym samym procesie, bez przełamywania sandboxa V8 i bez wykorzystywania klasycznej podatności typu memory corruption.
Najważniejszy wniosek jest prosty: logiczna izolacja na poziomie runtime nie zawsze gwarantuje pełne bezpieczeństwo na poziomie mikroarchitektury procesora. Jeżeli wiele obciążeń współdzieli proces, kanały boczne mogą stać się drogą do wycieku wrażliwych danych, takich jak tokeny JWT.
W skrócie
- Badacze zaprezentowali zdalny wariant ataku Spectre przeciwko Cloudflare Workers.
- W testach osiągnięto wyciek danych z szybkością do 12 bitów na sekundę przy skuteczności 99,16%.
- Atak wymagał współlokacji Workera atakującego i ofiary w tym samym procesie.
- Do pomiaru czasu wykorzystano komunikację WebSocket jako zdalny kanał obserwacji.
- Praktyczność scenariusza zwiększało użycie Durable Objects, które pozwalały utrzymać dłużej żyjącą instancję.
- Cloudflare poinformował o wdrożeniu mechanizmów ograniczających ryzyko, w tym ulepszeń DyPrIs, V8 Sandbox oraz izolacji pamięci opartej na MPK.
Kontekst / historia
Cloudflare Workers od początku rozwijane są jako lekka platforma uruchomieniowa oparta na izolacjach V8, co pozwala obsługiwać kod wielu klientów przy niskim narzucie startowym i wysokiej wydajności. Taki model ma jednak naturalny kompromis: im większe współdzielenie zasobów procesowych, tym większe znaczenie zyskują mikroarchitektoniczne kanały boczne.
Temat nie jest nowy. Od lat środowiska chmurowe i serverless są analizowane pod kątem podatności klasy Spectre, ale wcześniejsze demonstracje zdalnych wycieków były zwykle wolniejsze i mniej praktyczne operacyjnie. Obecne badanie pokazuje wyraźny postęp, ponieważ zwiększa przepustowość kanału bocznego i potwierdza możliwość przeprowadzenia ataku w produkcyjnej infrastrukturze, w warunkach kontrolowanych i bez dostępu do danych klientów.
Analiza techniczna
Sedno problemu wynika z faktu, że wiele izolacji V8 może współdzielić jeden proces systemowy. Chociaż każda izolacja jest odseparowana logicznie na poziomie języka i środowiska wykonawczego, procesor nadal może ujawniać informacje przez skutki uboczne wykonywania spekulacyjnego. To właśnie te efekty uboczne umożliwiają budowę kanału bocznego między tenantami.
W badaniu przygotowano dwa kontrolowane komponenty: Workera atakującego oraz Workera ofiary. W pamięci ofiary umieszczono token JWT, który następnie był odczytywany pośrednio przez mechanizm Spectre. Co istotne, atak nie wymagał kodu natywnego, exploita na silnik JavaScript ani ucieczki z sandboxa. Wystarczył poprawnie działający kod JavaScript uruchomiony po stronie atakującej.
Jednym z największych wyzwań w zdalnych atakach Spectre jest brak dokładnego źródła czasu. Platformy uruchomieniowe zwykle ograniczają precyzję timerów właśnie po to, by utrudnić pomiary kanałów bocznych. W tym przypadku wykorzystano komunikację WebSocket jako zdalny mechanizm pomiarowy, dzięki któremu możliwe było rozróżnianie subtelnych różnic wynikających z zachowania mikroarchitektury.
Drugim kluczowym elementem była możliwość wydłużenia życia instancji. Mechanizm Dynamic Process Isolation miał identyfikować podejrzane skrypty i przenosić je do odrębnego procesu po zakończeniu wywołania. Badacze wskazali jednak, że długowieczne wywołanie Durable Object mogło nadal działać przed momentem faktycznej izolacji, tworząc okno czasowe umożliwiające przeprowadzenie ataku.
Dodatkowo intensywne operacje wejścia-wyjścia związane z WebSocketami zwiększały aktywność iTLB, co osłabiało sygnał wykorzystywany przez mechanizmy detekcyjne. W praktyce oznaczało to, że wzorce I/O mogły utrudniać skuteczne rozpoznanie nadużycia opartego na błędnych predykcjach skoków i innych efektach ubocznych wykonywania spekulacyjnego.
W testach prowadzonych na serwerach z procesorami AMD EPYC opartymi na architekturach Zen 2 i Zen 3 osiągnięto przepustowość wycieku do 12 bitów na sekundę. Najlepsze wyniki pojawiały się przy niższym obciążeniu CPU, ale nawet przy większym obciążeniu atak pozostawał wykonalny, co wzmacnia jego praktyczne znaczenie.
Po stronie obrony Cloudflare wskazał zestaw zmian ograniczających ryzyko. Obejmują one ulepszenie DyPrIs, wdrożenie V8 Sandbox w celu utrudnienia przejściowego dostępu do wskaźników 64-bitowych oraz użycie Memory Protection Keys do izolacji pamięci wewnątrz procesu. To przykład podejścia warstwowego, łączącego mechanizmy programowe i sprzętowe.
Konsekwencje / ryzyko
Najważniejszą konsekwencją jest potwierdzenie, że środowiska serverless i edge compute współdzielące procesy między tenantami pozostają podatne na zaawansowane kanały boczne nawet wtedy, gdy nie występują klasyczne błędy pamięci. Wyciek JWT ma szczególne znaczenie, ponieważ taki token może otwierać dostęp do sesji użytkownika, interfejsów API lub innych zasobów aplikacyjnych.
Ryzyko praktyczne zależy od kilku czynników: możliwości współlokacji z ofiarą, długości życia instancji, obciążenia platformy, jakości kanału pomiarowego oraz wartości sekretów przechowywanych w pamięci. Chociaż scenariusz nie jest prosty operacyjnie, jego demonstracja w środowisku produkcyjnym zmienia ocenę zagrożenia z teoretycznego na praktyczne.
Dla operatorów platform wielodzierżawnych oznacza to konieczność ostrożnego bilansowania wydajności i poziomu izolacji. Dla klientów usług serverless to sygnał, że sekrety obecne w pamięci procesu powinny być traktowane jako potencjalnie narażone, zwłaszcza w modelu zagrożeń zakładającym zaawansowanego przeciwnika.
Rekomendacje
Organizacje korzystające z platform serverless powinny ograniczać czas życia oraz ekspozycję sekretów w pamięci. Tokeny JWT, klucze API i poświadczenia tymczasowe powinny mieć możliwie krótki czas ważności, minimalny zakres uprawnień i regularną rotację. Warto także projektować aplikacje tak, aby w runtime znajdowało się jak najmniej materiału uwierzytelniającego.
Z perspektywy architektury bezpieczeństwa kluczowe pozostaje podejście defense in depth. Obejmuje ono separację wrażliwych obciążeń, segmentację uprawnień, stosowanie krótkotrwałych poświadczeń, dodatkowe warstwy autoryzacji po stronie backendu oraz monitoring anomalii związanych z użyciem tokenów.
Zespoły deweloperskie i DevSecOps powinny przeanalizować, czy aplikacje przechowują długożyjące sekrety w pamięci procesu oraz czy korzystają z mechanizmów zwiększających czas życia instancji. Dotyczy to szczególnie komponentów takich jak WebSockety, Durable Objects i inne elementy utrzymujące stan, które mogą podnosić praktyczność ataku.
Dostawcy usług powinni z kolei stale rozwijać mechanizmy izolacyjne, wykorzystywać funkcje sprzętowe takie jak MPK, poprawiać telemetrię detekcyjną i regularnie walidować model zagrożeń z udziałem niezależnych badaczy. Sama detekcja behawioralna może nie wystarczyć, jeśli przeciwnik potrafi osłabiać obserwowane wskaźniki przez odpowiednio dobrane wzorce I/O.
Podsumowanie
Przypadek Cloudflare Workers pokazuje, że Spectre pozostaje realnym problemem dla nowoczesnych platform chmurowych, szczególnie tam, gdzie wielodzierżawność i niski narzut izolacji są podstawą modelu działania. Demonstracja wycieku JWT z szybkością do 12 bitów na sekundę podnosi praktyczny wymiar zagrożenia i przypomina, że granice bezpieczeństwa runtime nie zawsze pokrywają się z granicami bezpieczeństwa sprzętowego.
Dla branży to wyraźny sygnał, że bezpieczeństwo serverless wymaga łączenia ochrony na poziomie aplikacji, środowiska wykonawczego i sprzętu. Nawet jeśli dostawca wdrożył już środki zaradcze, temat mikroarchitektonicznych kanałów bocznych powinien pozostać wysoko na liście priorytetów zespołów odpowiedzialnych za bezpieczeństwo chmury.
Źródła
- Cloudflare Workers Spectre Attack Leaks JWT From Co-Located Worker at 12 Bits/Second — https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html
- Remote-Timer-as-a-Service: Efficient Microarchitectural Leakage in the Cloud with Remote Timers — https://arxiv.org/abs/2608.17043
- Safe in the sandbox: security hardening for Cloudflare Workers — https://blog.cloudflare.com/safe-in-the-sandbox-security-hardening-for-cloudflare-workers/
- Security model — Cloudflare Workers docs — https://developers.cloudflare.com/workers/reference/security-model/
- Workers Changelog — Cloudflare Workers docs — https://developers.cloudflare.com/workers/platform/changelog/