Atak Spectre na Cloudflare Workers ujawnił możliwość wycieku JWT między współlokowanymi izolacjami - Security Bez Tabu

Atak Spectre na Cloudflare Workers ujawnił możliwość wycieku JWT między współlokowanymi izolacjami

Cybersecurity news

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa opisali zdalny atak typu Spectre wymierzony w środowisko Cloudflare Workers, który pozwolił na odczyt tokenu JWT z pamięci współlokowanego Workera. To ważny przykład pokazujący, że nawet nowoczesne platformy serverless oparte na izolatach V8 mogą pozostawać podatne na wycieki bocznokanałowe wynikające z właściwości mikroarchitektury procesora.

Problem nie dotyczy klasycznej luki w kodzie aplikacji ani bezpośredniej ucieczki z sandboxa. Sedno zagrożenia polega na tym, że izolacja logiczna między tenantami nie zawsze przekłada się na pełną izolację na poziomie wykonania sprzętowego, zwłaszcza gdy wiele obciążeń współdzieli ten sam proces.

W skrócie

Atak został przeprowadzony w środowisku produkcyjnym z użyciem dwóch kontrolowanych przez badaczy komponentów: Workera atakującego i Workera ofiary. Celem było sprawdzenie, czy współdzielenie procesu systemowego przez wiele izolowanych tenantów może doprowadzić do wycieku danych pomiędzy izolacjami.

  • Udało się odczytać token JWT z pamięci współlokowanego Workera.
  • Maksymalna raportowana przepustowość wycieku wyniosła 12 bitów na sekundę.
  • Atak wykorzystywał właściwości wykonania spekulacyjnego procesora.
  • Cloudflare wdrożył dodatkowe mechanizmy ochronne, w tym ulepszenia Dynamic Process Isolation, V8 Sandbox oraz Memory Protection Keys.

Kontekst / historia

Cloudflare Workers od lat korzysta z modelu izolacji opartego na izolatach V8, a nie na pełnej separacji procesowej dla każdego uruchomienia. Takie podejście zapewnia bardzo niski czas startu i wysoką efektywność zasobów, ale od dawna jest analizowane pod kątem odporności na ataki bocznokanałowe, zwłaszcza z rodziny Spectre.

Wcześniejsze badania pokazały już możliwość przeprowadzenia zdalnego ataku Spectre przeciwko Workers, choć z dużo niższą przepustowością wycieku. W odpowiedzi opracowano Dynamic Process Isolation, czyli mechanizm mający wykrywać podejrzane wzorce wykonania i przenosić wybrane skrypty do osobnych procesów. Najnowsza demonstracja sugeruje jednak, że sam model detekcyjny może być niewystarczający wobec bardziej zaawansowanych technik obchodzenia zabezpieczeń.

Analiza techniczna

Kluczowy problem wynika z faktu, że wielu tenantów może wykonywać kod w oddzielnych izolatach V8, ale nadal wewnątrz tego samego procesu systemowego. Jeżeli atakujący i ofiara zostaną współlokowani, a atakujący uruchomi odpowiedni gadget Spectre, możliwe staje się spekulacyjne odczytywanie danych z pamięci poza granicami własnej izolacji.

Opisany scenariusz nie wymagał natywnego wykonania kodu, klasycznej podatności pamięciowej po stronie aplikacji ofiary ani pełnego przełamania sandboxa V8. Atak bazował na obserwacji subtelnych efektów mikroarchitektonicznych oraz na właściwościach wykonania spekulacyjnego procesora.

Badacze wykorzystali zdalne źródło czasu oparte na komunikacji WebSocket, co pozwoliło obejść ograniczenia lokalnych timerów. Dodatkowo Durable Objects umożliwiły utrzymanie długowiecznego wykonania, dzięki czemu proces wycieku mógł trwać przez wiele godzin bez przerwania.

Istotnym elementem było również osłabienie skuteczności Dynamic Process Isolation. Według opisu badaczy intensywna aktywność wejścia i wyjścia związana z WebSocketami zwiększała określone zdarzenia mikroarchitektoniczne i maskowała sygnał używany do detekcji podejrzanych zachowań. W praktyce złośliwy kod mógł więc pozostać aktywny dostatecznie długo, aby doprowadzić do wycieku danych.

Eksperyment przeprowadzono na serwerach z procesorami AMD EPYC opartymi na architekturach Zen 2 i Zen 3. Najlepsze wyniki osiągnięto przy niskim obciążeniu systemu, choć autorzy wskazali, że wolniejszy wyciek pozostaje możliwy także przy większym obciążeniu środowiska.

Konsekwencje / ryzyko

Z perspektywy bezpieczeństwa chmury to ważny sygnał ostrzegawczy dla wszystkich platform wielodostępnych opartych na współdzieleniu procesu lub runtime’u. Atak pokazał, że granice bezpieczeństwa definiowane na poziomie języka i środowiska uruchomieniowego mogą nie wystarczać wobec nowoczesnych kanałów bocznych CPU.

Ryzyko praktyczne zależy jednak od kilku warunków. Konieczna jest współlokacja ofiary i atakującego, możliwość utrzymania długotrwałego wykonania, obecność wartościowych sekretów w pamięci oraz sprzyjające parametry obciążenia hosta. Nie jest to zatem scenariusz masowy ani prosty do wykorzystania, ale dla środowisk przetwarzających tokeny sesyjne, klucze API i dane uwierzytelniające skutki mogą być poważne.

  • Możliwy jest wyciek JWT i innych sekretów przetrzymywanych w pamięci procesu.
  • Zagrożone są modele bezpieczeństwa oparte głównie na izolacji logicznej.
  • Incydent podnosi znaczenie zagrożeń mikroarchitektonicznych w chmurze i edge computingu.
  • Klienci usług serverless powinni ostrożniej traktować przechowywanie wrażliwych danych w runtime.

Rekomendacje

Organizacje korzystające z platform serverless powinny ograniczać czas życia sekretów w pamięci i unikać przechowywania ich w globalnym stanie aplikacji dłużej, niż to konieczne. Tokeny JWT, klucze API i dane sesyjne powinny być przetwarzane możliwie krótko oraz regularnie rotowane.

Warto wdrożyć architekturę minimalizacji zaufania do pamięci runtime’u. Obejmuje to segmentację sekretów, krótkoterminowe poświadczenia, częstą rotację tokenów oraz pobieranie wrażliwych danych tylko w momencie użycia. Dodatkową korzyść daje ograniczenie nadmiarowego cache’owania poufnych informacji w warstwie aplikacyjnej.

Z perspektywy dostawców usług kluczowe jest wielowarstwowe podejście obronne, łączące izolację architektoniczną, wzmacnianie sandboxa, zabezpieczenia sprzętowe oraz monitorowanie anomalii wykonania. Mechanizmy detekcyjne nie powinny pozostawać jedyną linią obrony.

  • Skracać czas przebywania sekretów w pamięci.
  • Stosować krótkoterminowe tokeny i częstą rotację poświadczeń.
  • Minimalizować współdzielenie stanu między komponentami.
  • Regularnie przeglądać model zagrożeń dla środowisk edge i FaaS.
  • Rozważać dodatkową separację dla workloadów przetwarzających szczególnie wrażliwe dane.

Podsumowanie

Najnowsze badanie dotyczące Spectre na Cloudflare Workers pokazuje, że ataki bocznokanałowe nadal stanowią realne wyzwanie dla nowoczesnych środowisk serverless i edge. Demonstracja wycieku JWT między współlokowanymi izolacjami V8 nie oznacza kompromitacji całej platformy, ale wyraźnie podkreśla ograniczenia modeli bezpieczeństwa opartych na współdzieleniu procesu.

Najważniejszy wniosek jest praktyczny: skuteczna ochrona przed Spectre i podobnymi klasami zagrożeń wymaga połączenia izolacji architektonicznej, zabezpieczeń sprzętowych, utwardzania runtime’u oraz rygorystycznego zarządzania sekretami po stronie aplikacji.

Źródła

  • https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html
  • https://arxiv.org/abs/2608.17043
  • https://blog.cloudflare.com/safe-in-the-sandbox-security-hardening-for-cloudflare-workers/
  • https://arxiv.org/abs/2110.04751
  • https://developers.cloudflare.com/workers/reference/security-model/