Cloudflare behebt kritische Sicherheitslücke, die Kundendaten in gemeinsam genutzten Containern offenlegte

Cloudflare hat eine Sicherheitslücke in seiner gemeinsam genutzten Container-Infrastruktur geschlossen, durch die zahlende Kunden unter bestimmten Bedingungen auf Daten zugreifen konnten, die von anderen Mandanten zurückgeblieben waren. Das Unternehmen erklärte in einer Offenlegung vom 24. September, dass in den verfügbaren historischen Telemetriedaten keine Hinweise auf eine böswillige Ausnutzung gefunden worden seien und Kunden keine Maßnahmen ergreifen müssten. Pasted markdown

Forscher entdecken mögliche Offenlegung sensibler Dateien

Die Schwachstelle betraf die Trennung gespeicherter Daten zwischen verschiedenen Kunden. Nach Angaben des Sicherheitsteams von Accomplish ermöglichte ein Fehler bei der Festplattenisolierung einer Sandbox, Dateien anderer Kunden auszulesen.

Zu den gemeldeten Daten gehörten unter anderem Verzeichnislisten, SQLite-Datenbanken, Chromium-Profile, Umgebungskonfigurationen und Dateien mit Zugangsdaten. Cloudflare Sandboxes und Browser Run nutzten laut den Forschern dieselbe betroffene Festplattenimplementierung. Der Fehler wurde Cloudflare am 4. September gemeldet.

Die potenziell betroffenen Dateitypen sind insbesondere für Unternehmen relevant, die vertrauliche Informationen in Cloud-Umgebungen verarbeiten. Konfigurations- und Zugangsdaten können beispielsweise Anwendungseinstellungen oder Zugriffsschlüssel enthalten, während Browserprofile und Datenbanken Informationen aus laufenden Sitzungen speichern können.

Die Entdeckung belegt jedoch nicht, dass Kriminelle diese Informationen tatsächlich abgegriffen oder Kundenkonten kompromittiert haben.

Wie die Wiederverwendung von Speicher zur Schwachstelle führte

Cloudflare führte die Sicherheitslücke auf die Einstellung skip_block_zeroing zurück. Dabei konnte ein Schreibvorgang von 4 KiB innerhalb eines zugewiesenen 64-KiB-Blocks dazu führen, dass 60 KiB ältere Daten im Speicher verblieben.

Angreifer konnten weder gezielt einen bestimmten Kunden auswählen noch eine aktiv eingebundene Festplatte auslesen. Ein möglicher Zugriff hing vielmehr von der Speicherzuweisung und der Wiederverwendung bereits genutzter Blöcke ab.

Speicherzuweisung und Datenlöschung sind unterschiedliche Prozesse

Bei Thin Provisioning wird virtueller Speicher nach Bedarf durch physische Kapazität bereitgestellt. Wird ein Speicherblock anschließend einem neuen Workload zugewiesen, bedeutet dies nicht automatisch, dass sämtliche zuvor darin gespeicherten Informationen überschrieben wurden.

Genau diese Unterscheidung war für die Schwachstelle entscheidend. Die Zuweisung bestimmt, welcher Workload auf einen Speicherbereich zugreifen darf. Das Löschen beziehungsweise Überschreiben entscheidet dagegen darüber, ob Informationen des vorherigen Nutzers weiterhin vorhanden sind.

Auch das Freigeben eines Speicherbereichs, das Entfernen einer Zuordnung und das tatsächliche Unwiederbringlichmachen früherer Inhalte sind technisch unterschiedliche Vorgänge.

Virtuelle Maschinen verhindern nicht jedes Isolationsrisiko

Cloud-Plattformen setzen verschiedene Virtualisierungstechnologien ein, um Workloads voneinander zu trennen. Firecracker beispielsweise kombiniert leichtgewichtige MicroVMs mit Sicherheitsmechanismen wie KVM, eingeschränkten Systemaufrufen, Ressourcenkontrollen und reduzierten Prozessrechten.

Eine virtuelle Maschine benötigt jedoch weiterhin Speicher, der vom Host-System bereitgestellt wird. Dadurch entsteht eine zusätzliche Abhängigkeit zwischen der Virtualisierungsschicht und den Ressourcen, die einer VM zugewiesen werden.

Für Sicherheitsprüfungen bedeutet dies, dass nicht nur mögliche Ausbrüche aus einer virtuellen Umgebung untersucht werden sollten. Auch Speicheraufbereitung, Wiederverwendung, Snapshots und Bereinigungsprozesse gehören zu einer umfassenden Bewertung der Mandantentrennung.

Cloudflare bereinigte auch bestehende Ressourcen

Cloudflare aktivierte die Nullsetzung von Speicherblöcken wieder und entfernte Container-Festplatten sowie zwischengespeicherte Image-Snapshots, die vor der Korrektur erstellt worden waren.

Die Einführung der technischen Korrektur wurde am 7. September abgeschlossen. Die Bereinigung der Snapshots folgte bis zum 19. September. Die Sicherheitsforscher bestätigten anschließend, dass ihr Proof of Concept nicht mehr funktionierte.

Diese Vorgehensweise verdeutlicht einen wichtigen Aspekt der Cloud-Sicherheit: Eine Konfigurationsänderung kann zukünftige Datenexposition verhindern, während bereits vorhandene Ressourcen weiterhin bereinigt werden müssen.

Bedeutung für KI-Agenten und Entwicklerplattformen

Die Schwachstelle ist auch für Dienste relevant, die im Auftrag ihrer Nutzer Code ausführen. Cloudflare beschreibt seine Sandbox-Technologie unter anderem für KI-Agenten, Datenanalysen, interaktive Entwicklungsumgebungen und Build-Pipelines.

Solche Systeme können Quellcode, Geschäftsdaten oder temporäre Dateien verarbeiten. Das bedeutet allerdings nicht, dass genau diese Inhalte im vorliegenden Fall tatsächlich offengelegt wurden.

Eine Möglichkeit zur Risikobegrenzung besteht darin, sensible Zugangsdaten möglichst außerhalb von Ausführungsumgebungen zu halten. Dies behebt zwar keine Schwachstelle beim Cloud-Anbieter selbst, kann aber reduzieren, wie viele vertrauliche Informationen innerhalb einer Sandbox gespeichert werden.

Was Unternehmen aus dem Vorfall ableiten können

Für Sicherheitsteams zeigt der Fall, dass die Bewertung von Cloud-Anbietern den gesamten Lebenszyklus gemeinsam genutzter Ressourcen berücksichtigen sollte. Dazu gehören die Löschung von Daten, die Behandlung von Snapshots und Caches sowie die Frage, wann wiederverwendeter Speicher tatsächlich bereinigt wird.

Cloudflares Aussage, keine Hinweise auf eine böswillige Ausnutzung gefunden zu haben, beschreibt das Ergebnis der eigenen Untersuchung. Gleichzeitig bedeutet das Vorhandensein der Schwachstelle nicht automatisch, dass sämtliche Kunden von einem tatsächlichen Datenabfluss betroffen waren.

Der Vorfall unterstreicht damit eine grundlegende Anforderung an gemeinsam genutzte Cloud-Infrastrukturen: Die Isolation muss nicht nur zwischen gleichzeitig laufenden Workloads funktionieren, sondern auch verhindern, dass Daten eines früheren Kunden für einen nachfolgenden Nutzer sichtbar bleiben.