Studie zeigt Remote-Variante von Spectre, die einen JWT in Cloudflare Worker Speicher filtert

Security-Forscher haben ein kontrolliertes Experiment veröffentlicht, das eine Remote-Variante von Spectre zeigt, die in der Lage ist, einen JSON Web Token (JWT) zu filtern, der im Speicher eines anderen Cloudflare Worker-Co- innerhalb desselben Prozesses mit einer maximalen Exfiltrationsrate von bis zu 12 Bit pro Sekunde. Im End-to-End-Test führten die Autoren einen angreifenden Arbeiter und einen "victim" Arbeiter unter ihrer Kontrolle durch und legten den JWT bewusst in den zweiten Speicher, um den Kanal zu messen. Cloudflare bestätigte, dass das Experiment nicht auf Kundendaten zugreift und dass es bereits Produktionsminderung eingesetzt hat; das Unternehmen erklärte auch, dass es in den letzten drei Jahren keine aktiven Betriebsindikatoren gefunden habe.

Fact-finding: Die Technik basiert auf einer Version der sogenannten "Transit-Ausführung" oder Spectre-Angriffe, bei der spekulative und mikroarchitecturale Messwerte zu Seitenkanälen der Zeit werden, um Bits von einer anderen Ausführung zu filtern. In der Umgebung von Cloudflare Workers ist dies nur möglich, wenn der Angreifer und das Opfer zusammengefügt werden verschiedene V8-Isolate innerhalb desselben Prozesses. Die Arbeit der Forscher beschreibt zwei Schlüsselfaktoren, die die Flucht erleichtert: erstens, dass ein Remote-Terminalkanal mit WebSockets möglich war (die Arbeiter nicht lokale Quellen mit hoher Auflösung Timing aussetzen); zweitens, dass die dauerhaften Objekte eine Insel für Stunden aktiv bleiben lassen, die dynamische Isolationspolitik (DyPrIs) daran hindert, den Code sofort in einen separaten Prozess zu verlagern.

Technisch bedingt der Angriff nicht die Ausführung von nativem Code oder einer V8- oder "escape"-Verwundbarkeit aus der Sandbox: Der Gegner führt legitimen Code aus seinem eigenen Isolat aus und nutzt Mikroarchitekturalsignale (wie iTLB-Zustände und Astprognosen) aus, um über eine Remoteverbindung beobachtbare Effekte zu induzieren und zu messen. Forscher dokumentierten auch, dass intensive I / O-Ladungen von WebSockets die iTLB-Aktivität erhöhen und das von DyPrIs verwendete Detektionssignal reduzieren - die Cloudflare-Huristiken, um zu entscheiden, wann ein verdächtiges Isolat in einen anderen Prozess verschoben wird. Nach dem Papier erlaubte diese Verringerung des Signals die Detektion nicht zu feuern, während das Leck auftrat.

Bestätigt von Cloudflare: Arbeiter führen mehrere Mieter in V8-Isolaten innerhalb des gleichen Prozesses mit dem Ziel, Start-Latenz zu reduzieren, und ihre Verteidigung DyPrIs bewegt verdächtige Isolate zu trennen Prozesse nach einer Invokation. Nach der Offenlegung beschreibt Cloudflare, erweiterte DyPrIs, integriert die "V8 Sandbox" (begrenzter Durchgangszugriff auf 64-Bit-Pointer) und implementierte ein prozessbasiertes Isolationsschema basierend auf Memory Protection Keys (MPK) - eine CPU-Funktion, die es erlaubt, Speicherbereiche mit Hardware-Schlüsseln zu schützen - um die Möglichkeit der Kreuzlesung zwischen isolates Heaps zu reduzieren.

Reproduktionsdaten aus der Studie: Die Experimente wurden auf Linux-Servern mit AMD EPIC Zen 2 und Zen 3 Prozessoren durchgeführt; um die maximale Exfiltrationsrate zu erhalten, arbeiteten die Autoren an Tieflastfenstern (10-25% Nacht CPU) und berichteten eine Genauigkeit von 99,16% in Bit-Recovery mit der maximalen Rate. Die Autoren machen deutlich, dass mit mehr Systemlast die Geschwindigkeit abnimmt, aber die Technik bleibt tragfähig, aber langsamer. Historischer Vergleich: der bisherige, 2021 von Cloudflare und TU Graz veröffentlichte Fernangriff auf Arbeiter erreichte etwa 120 Bit pro Stunde (~ 2 Bit / Minute); die neue Messung stellt eine signifikante Verbesserung der Rate dar (bis etwa 360 mal schneller unter kontrollierten Bedingungen).

Was dies für Nutzer von Workers und Cloud-Diensten bedeutet: In der Praxis zeigt die Technik, dass unter bestimmten Bedingungen ein Schauspieler mit legitimem Code auf derselben Plattform eingesetzt kann - theoretisch - geheime, die in Erinnerung an andere Mieter gespeichert werden. Der Test durchlief ein JWT, eine Art Geheimnis, das API-Zugriff oder Sitzungsvalidierungen erlauben kann, wenn es nicht rechtzeitig gebunden ist. Obwohl die Fähigkeit, Zehner von Bits pro Sekunde zu exfiltrieren, noch einen relativ langsamen Prozess, um lange Geheimnisse zu erhalten, Automatisierung und Wiederholung ermöglichen, Schlüssel oder Token im Laufe der Zeit rekonstruieren.

Was bestätigt wird und was noch unsicher bleibt: Es wird bestätigt, dass die Technik im Labor gegen die Pre-Patch-Produktionskonfiguration arbeitet und dass Cloudflare eine Minderung eingesetzt hat. Es wird nicht bestätigt, dass es in realen Kunden Ausbeutung gegeben hat; Cloudflare meldet keine Indikatoren in den letzten drei Jahren. Es ist unsicher, inwieweit die Minderungen (verbesserte DyPrIs-Kombination, V8 Sandbox und MPK) alle praktischen Ausbeutung in allen Szenarien und Architekturen eliminieren und wie viel Leistung oder Kompatibilität sie im Maßstab haben.

Mögliche reale Konsequenzen: Für Lasten, die lange Arbeiter im Gedächtnis halten (z.B. dauerhafte Objekte mit langer Invokation) oder die intensive WebSockets verwenden, besteht ein höheres Risiko ausnutzbarer Co-Location. Langfristige Geheimnisse, die im Workers'-Speicher gespeichert werden (API-Tasten, JWT mit umfassenden TTL, global variable Anmeldeinformationen) sind die verletzlichsten Vermögenswerte. Für mehrstufige Umgebungen, in denen Co-Location üblich ist, unterstreicht diese Art von Kanal die Spannung zwischen Latenzoptimierung und Prozessreinigungsisolierung.

Spezifische Empfehlungen für Entwickler und Administratoren: Zuerst, behandeln Sie Geheimnisse als kurzfristig: reduzieren Sie Token TTL, oft kritische Schlüssel rote und Anwendung Umfang Grenzen. Vermeiden Sie sensible Geheimnisse in globalen Variablen in Workers; verwenden Sie Bindungen von verwalteten Geheimnissen und externen Dienstleistungen mit zusätzlichen Kontrollen (z.B. OAuth mit kontrollierter Erfrischung). Für Architekturen, die Durable Objects oder WebSocket-Verbindungen verwenden, betrachten die Verengung der Lebensdauer der langen Invokation oder Fragmentierung Zustand, um Oberflächen im Speicher zu minimieren. Aktivieren und überprüfen Sie Ihre Lieferantenrichtlinien und Login, um Co- ungewöhnliche Standorte oder lange WebSocket Muster zu erkennen. Wenn Sie mit sehr sensiblen Daten umgehen, bewerten Sie die Ausführung in prozessisolierten Umgebungen oder dedizierten Instanzen.

Empfehlungen für Plattformbetreiber: Real-time-Erkennung während der Ausführung (nicht nur nach dem Aufruf) und Verwendung von Signalen, die durch I / O-Aktivität nicht leicht gedämpft werden können Kombination von Hardware-Schutz wie MPK mit V8-Sandboxing und Drehspeicher-Layouts reduziert die Wahrscheinlichkeit, dass zwei Isolate den gleichen Schutzschlüssel teilen, aber diese Maßnahmen sollten vor realen Belastungen und mehreren CPU-Architekturen ausgewertet werden. Bewahren Sie proaktive Audits und Suchanfragen von fernen Timing-Mustern mit WebSockets als Kanal und begrenzen Sie die Belichtung von persistenten Verbindungen, wenn nicht notwendig.

Quellen und zusätzliche Lektüre: ursprüngliche technische Erklärung von Spectre https: / / / spectreattack.com / spectre.pdf, und die Dokumentation von Cloudflare Workers, um das operative Modell von Isolaten und dauerhaften Objekten zu verstehen https: / / entwickelt. Weitere Informationen zu Memory Protection Keys in CPU x86 finden Sie in der Intel Anleitung auf MPK https: / / www.intel.com / content / www / us / en / entwickelt / Artikel / technische / speicher-protection-keys.html.

Kurz gesagt, die Forschung eröffnet die Diskussion über die Sicherheit des Angebots von Sprach-Level Isolation (V8 isolates) innerhalb des gleichen Prozesses, um Latenz zu optimieren. Die von Cloudflare bereitgestellten Minderungen reduzieren die Angriffsfläche, aber die gemeinsame Verantwortung liegt auch bei Entwicklern und Betreibern: geheime Lebenszeiten zu minimieren, lange Betriebsmuster im Speicher zu vermeiden und die intensive Nutzung von WebSockets zu überprüfen sind praktische Schritte, die die Exposition begrenzen und die Wirksamkeit der Schutzmaßnahmen im Maßstab weiter bewerten.