Thought Leadership
Sicherheitsforscher haben einen Spectre-Angriff gegen Cloudflare Workers offengelegt. Er liest JWT-Token aus.
Cloudflare Workers führt Code unterschiedlicher Kunden in separaten V8-Isolaten innerhalb desselben Betriebssystemprozesses aus und setzt dabei auf eine Isolierung auf Sprachebene statt auf strikt getrennte Prozesse, um die Startzeit einzelner Worker möglichst kurz zu halten. Wie Cloudflare selbst einräumt, kann ein Speicherzugriff innerhalb eines gemeinsam genutzten Worker-Prozesses dabei grundsätzlich zu einem Datenabfluss zwischen unterschiedlichen Kunden führen. Voraussetzung für den nun beschriebenen Angriff ist, dass sich angreifender und betroffener Worker zufällig als separate V8-Isolate im selben Worker-Prozess befinden. Der eigentliche Angriff basiert dabei nicht auf einem Softwarefehler in V8 oder einem Ausbruch aus der Sandbox, sondern nutzt ausschließlich regulären, im eigenen Isolat gültigen Code des Angreifers.
Da Cloudflare lokale Zeitquellen während der Prozessorausführung bewusst einfriert oder ungenauer macht und Workern weder gemeinsam genutzten Speicher noch Multithreading zugänglich macht, mussten die Forscher einen alternativen Weg zur präzisen Zeitmessung finden. Sie fanden diesen in WebSocket-Kommunikation, die als entfernte Zeitquelle diente, während sich sogenannte Durable Objects nutzen ließen, um ein einzelnes Worker-Isolat über fünf bis mehr als 20 Stunden am Leben zu halten.
Erkennungsmechanismus DyPrIs gezielt unterlaufen
Cloudflares bestehender Schutzmechanismus namens Dynamic Process Isolation, kurz DyPrIs, verschiebt verdächtige Skripte nach Abschluss eines Aufrufs in einen separaten Prozess. Die Forscher stellten jedoch fest, dass ein langlebiger Durable-Object-Aufruf weiterlaufen konnte, bevor diese Isolierung überhaupt griff. Zusätzlich fanden sie, dass intensive WebSocket-Ein- und Ausgabeaktivität die Auslastung des sogenannten Instruction Translation Lookaside Buffer erhöhte und dadurch das von DyPrIs zur Erkennung genutzte, normalisierte Signal für Sprungvorhersagefehler unter den eigentlichen Erkennungsschwellenwert drückte.
Die Forscher erklärten dazu in ihrer Veröffentlichung, die produktive Umsetzung von DyPrIs habe sich als unzureichend erwiesen. Während Cloudflare das Problem als Grenze der eigenen DyPrIs-Umsetzung einordnet, beschreiben die Forscher beide gefundenen Schwächen als grundsätzliche Grenzen des gewählten Erkennungsansatzes selbst, nicht als bloßes Umsetzungsversehen, und empfehlen, eine robuste Erkennung stattdessen während der laufenden Ausführung vorzunehmen und dafür ein Signal zu nutzen, das sich nicht durch Ein- und Ausgabeaktivität unterdrücken lässt.
Nächtliche Tests unter geringer Serverlast
Die produktiven Tests führten die Forscher nach eigenen Angaben auf Linux-Servern mit AMD-EPYC-Prozessoren der Generationen Zen 2 und Zen 3 durch, bewusst nachts bei einer Prozessorauslastung von nur 10 bis 25 Prozent, um möglichst gute Ergebnisse zu erzielen. Bei höherer Systemlast sank die beobachtete Datenrate zwar deutlich, langsamere Varianten des Angriffs blieben den Forschern zufolge jedoch auch dann grundsätzlich durchführbar. Insgesamt erreichte der Angriff dabei eine Datenrate von bis zu 12 Bit pro Sekunde bei einer Genauigkeit von 99,16 Prozent, verglichen mit lediglich 2 Bit pro Minute beim ursprünglichen, 2021 gemeinsam von Cloudflare und der TU Graz veröffentlichten Angriff, der DyPrIs als Gegenmaßnahme einführte und damals eine Falsch-Positiv-Rate von 0,61 Prozent sowie nach eigener Einschätzung vergleichbare Sicherheitsgarantien wie eine strikte Prozessisolierung auswies.
Mehrschichtige Nachbesserung im produktiven Betrieb
Als Reaktion verbesserte Cloudflare zunächst die Erkennungsfähigkeiten von DyPrIs selbst, integrierte zusätzlich die sogenannte V8 Sandbox, die den zeitweiligen Zugriff auf 64-Bit-Zeiger einschränkt, und führte eine auf sogenannten Memory Protection Keys basierende prozessinterne Isolierung ein, die den Speicherbereich einzelner Worker zusätzlich hinter hardwaregestützten Schutzschlüsseln platziert. Nach eigenen Angaben stehen auf modernen x64-Systemen dafür nur rund 12 solcher Schlüssel zur Verfügung, weshalb Cloudflare diese mit der V8 Sandbox sowie einem rotierenden Speicherlayout kombiniert, damit benachbarte Sandboxes sich keinen gemeinsamen Schlüssel teilen.
Eine rein zufällige Zuteilung der Schlüssel allein hätte laut einer bereits im September 2025 veröffentlichten Beschreibung von Cloudflare nur rund 92 Prozent der Zugriffe zwischen unterschiedlichen Isolaten abgefangen, da zwei Isolate dabei denselben Schlüssel erhalten können, weshalb das striktere, rotierende Layout eingesetzt wird, um diese verbleibende Lücke innerhalb des betrachteten Bedrohungsmodells zu schließen. Cloudflare erklärte, in den vergangenen drei Jahren keine Hinweise auf eine tatsächliche Ausnutzung der Schwachstelle gefunden zu haben, das zugrunde liegende Forschungsexperiment selbst erfolgte mit eigens von den Forschern kontrollierten Angreifer- und Opfer-Workern, auf echte Kundendaten wurde dabei nach Angaben der Forschungsarbeit zu keinem Zeitpunkt zugegriffen.
(red)
