Zusammenfassung

  • Eine HTML-Transformation konnte über ihren Puffer hinaus lesen und Fragmente anderer Anfragen in Antworten schreiben; die erwartete Trennung zwischen Kunden desselben Edge-Prozesses brach zusammen.
  • Kill-Switches und Parserkorrektur stoppten neue Offenlegungen. Bereits gespeicherte Antworten und möglicherweise kompromittierte Zugangsdaten verlangten jedoch einen zweiten Wiederherstellungsprozess, dessen Abschluss der Patch nicht beweisen konnte.

Auslöser und Opfer waren verschiedene Rollen

Am 17. Februar 2017 meldete Googles Project Zero an Cloudflare, dass ausgelieferte Seiten fremde Datenfragmente enthielten. Dazu gehörten Cookies, Authentifizierungstoken, POST-Inhalte und weitere Teile des Prozessspeichers. Einige Antworten waren bereits von Suchmaschinen zwischengespeichert worden.

Der Name Cloudbleed erinnert an Heartbleed. Hier war aber die Mehrmandantenarchitektur entscheidend. Ein gemeinsamer Dienst transformierte Seiten vieler Kunden. Fehlerhaftes HTML einer Domain konnte den Pfad auslösen, während die angrenzenden Bytes aus der Anfrage eines anderen Kunden stammten.

Die Liste der auslösenden Domains ist deshalb kein Opferverzeichnis. Ein Kunde musste die betroffene Funktion nicht nutzen; seine Anfrage musste nur im falschen Augenblick denselben Prozess teilen. Verletzt wurde nicht bloß die Regel, ein Dokument korrekt zu parsen. Verletzt wurde die Isolationsregel, dass Arbeit für einen Mandanten niemals Speicher eines anderen lesen oder aussenden darf.

Neue Pufferung traf auf einen alten Zeigerfehler

Cloudflare fand den Defekt in älterem, mit Ragel erzeugtem Code für drei HTML-Funktionen: E-Mail-Verschleierung, Server-Side Excludes und automatische HTTPS-Umschreibung. Ein fehlendes fhold konnte einen Zeiger am Pufferende stehen lassen. Der Aufrufer behandelte das Ergebnis als gültigen Bereich und kopierte über die Grenze hinaus.

Die Häufigkeit stieg nach der Einführung des Parsers cf-html, der die Pufferung veränderte. Cloudflare grenzte die Ursache ausdrücklich ein: Der Fehler lag weder in Ragel selbst noch in cf-html. Die neue Komponente veränderte die Umgebung des Altbestands und machte einen schlummernden Defekt häufiger sichtbar.

Eine isolierte Prüfung der neuen Komponente reicht für solche Übergänge nicht. Rollouts müssen exakte Puffergrenzen, Unterschiede zum alten Verhalten und die Abstürze aller alten Verbraucher prüfen, die durch den neuen Pfad wieder aktiv werden.

Eine Abschaltfolge mit absoluten Uhrzeiten

Die erste Kontrollmöglichkeit lag beim Edge-Betreiber. Die detaillierte UTC-Zeitleiste vermerkt den Eingang der Fehlerdetails am 18. Februar um 00:32 Uhr, die weltweite Abschaltung der E-Mail-Verschleierung um 01:19 Uhr, der automatischen HTTPS-Umschreibung um 04:24 Uhr und den weltweiten Rollout des Patches mit dem cf-html-Schalter um 07:22 Uhr. Server-Side Excludes besaß keinen eigenen globalen Schalter; er musste während des Vorfalls gebaut und ausgerollt werden.

Ein Kill-Switch ist kein bloßer Betriebskomfort. Er gehört zum Sicherheitsmodell der Funktion. Ohne ihn wird unter Incident-Druck neuer Code benötigt. Mit ihm kann eine optionale Transformation verschwinden, während unabhängige Proxyfunktionen weiterlaufen.

Private SSL-Schlüssel der Kunden waren laut Cloudflare über diesen Pfad nicht erreichbar, weil die TLS-Terminierung in einer getrennten NGINX-Instanz lief. Im HTTP-Prozess befanden sich jedoch ein privater Schlüssel für die Verschlüsselung zwischen Cloudflare-Maschinen und einige interne Authentifizierungsgeheimnisse. Prozessisolation schützte eine besonders folgenschwere Klasse, machte die erreichbare Geheimnismenge aber nicht leer.

Die spätere Neuentwicklung in Rust setzte eine stärkere lokale Schranke: Sicherer Code verhindert gewöhnliche Speicherzugriffe außerhalb des Bereichs. Das entfernt eine Fehlerklasse, statt jeden Zeigerfehler durch Review finden zu müssen. Autorisierungsfehler, unsichere Bibliotheken und falsche Datenflüsse löst Rust nicht automatisch.

Die Rate war eine Schätzung, keine Volkszählung

Der erste Bericht nannte den 13. bis 18. Februar als stärkste Expositionsphase und schätzte etwa eine potenziell leckende Anfrage auf 3,3 Millionen, rund 0,00003 Prozent. Die spätere Auswertung schätzte 1.242.071 Auslösungen zwischen dem 22. September 2016 und dem 18. Februar 2017: 605.037 vor dem 13. Februar von weniger als 180 Sites und 637.034 in den letzten fünf Tagen von 6.457 Sites.

Die Detailprotokolle waren nur zu einem Prozent erfasst und für den 8. bis 18. Februar vorhanden. Ältere Detaildaten waren bereits gelöscht; frühere Zeiträume wurden aus Aggregaten und Crashdaten modelliert. Cloudflare fand in den untersuchten Aufzeichnungen keinen Hinweis auf böswillige Ausnutzung. Das beweist nicht, dass sie nie stattgefunden hat.

Auslösungen sind keine eindeutigen Opfer. Ein globaler Durchschnitt sagt nichts über die Sensibilität eines einzelnen Tokens. Eine erfolglose Suche in einer Stichprobe schließt die Vergangenheit nicht ab.

Der Patch konnte ausgesandte Bytes nicht zurückrufen

Das Abschalten beendete neue kontaminierte Antworten, nicht bereits ausgelieferte Kopien. Cloudflare schätzte, dass Suchcrawler mehr als die Hälfte der Auslösungen erzeugten, ließ über 80.000 eindeutige Cache-Seiten entfernen und fand in fremden Caches Daten, die 150 Kunden zugeordnet waren.

Keine Zahl ist eine Obergrenze. Nicht jede entfernte Seite enthielt zwingend ein Geheimnis; 150 identifizierte Kunden bedeuten nicht nur 150 betroffene; eine Cache-Löschung beweist keine Abwesenheit privater Kopien. Eindämmung und Wiederherstellung haben verschiedene Endkriterien.

Die Parserkorrektur zeigt nur, dass der bekannte Pfad unter getesteten Bedingungen keine neuen Lecks erzeugt. Cache-Betreiber müssen ihre Kopien löschen. Kunden müssen Sitzungen, Token, API-Schlüssel und Passwörter bei jedem vertrauenden System widerrufen oder ersetzen. Die nützliche Evidenz ist die Ablehnung des alten Geheimnisses, nicht die Ausgabe eines neuen.

Minimale gemeinsame Grenze, reversible lokale Entscheidungen

Heng Lus Running-Code Primacy verlangt beobachtbare Ergebnisse: keine fremden Speicherfragmente in laufenden Antworten, prüfbarer Funktionsstatus, unwirksame alte Zugangsdaten und von den tatsächlichen Cache-Eigentümern bearbeitete Reste. Ein Statusvermerk „gelöst“ erzeugt keinen dieser Nachweise.

Die Minimum Initial Specification kann kurz und absolut sein: Eine Antwort enthält nur Daten, die für genau diese Antwort autorisiert sind. Optionale Transformationen, Parserwahl, Rolloutzeit und Abschaltung bleiben lokale Entscheidungen. Sie können sich ändern oder abgelehnt werden, ohne die gemeinsame Isolation zu schwächen oder jedem Kunden dasselbe Funktionsrisiko aufzuzwingen.

Cloudbleed widerlegte nicht die geteilte Infrastruktur. Der Vorfall zeigte, dass Teilen eine harte Membran verlangt und dass jeder optionale Pfad durch diese Membran vor dem Gesamtdienst verschwinden können muss.

Quellen