HTTP/2-Continuity-Flood: Technische Details

HTTP/2-CONTINUATION-Flood-Schwachstelle: Technische Details

• CONTINUATION Flood ist eine Kategorie von Schwachstellen, die in mehreren HTTP/2-Protokollimplementierungen gefunden wurden, und stellt eine noch ernstere Bedrohung dar als der Rapid-Reset-Angriff.
• Die Auswirkungen des Angriffs reichen von Serverabstürzen bis hin zu Leistungseinbußen, und die Angriffsanfragen erscheinen nicht in den HTTP-Zugriffslogs.

Vorwort

• Im Oktober 2023 wurde die HTTP/2-Rapid-Reset-Attacke bekannt, woraufhin entschieden wurde, die Untersuchung aus der Perspektive einer Sicherheitsanalyse von HTTP/2 zu beginnen.

Eine kurze Einführung in HTTP/2

• Der Hauptunterschied zwischen HTTP/1.1 und HTTP/2 besteht darin, dass Letzteres ein binäres Protokoll ist und Client und Server statt Textzeilen Frames austauschen.
• Eine Erklärung der HEADERS-Frames und CONTINUATION-Frames ist erforderlich.

HEADERS-Frames

• HEADERS-Frames werden verwendet, um HTTP-Header von Anfragen und Antworten zu übertragen, und komprimieren die Headerdaten mit dem HPACK-Kodierungsalgorithmus.
• Für Frames können Flags wie END_HEADERS und END_STREAM gesetzt werden.

CONTINUATION-Frames

• CONTINUATION-Frames sind HEADERS-Frames sehr ähnlich, besitzen jedoch nur das Flag END_HEADERS; wenn dieses gesetzt ist, bedeutet das das Ende des Header-Streams.

CONTINUATION-Flood-Schwachstelle

• Wenn ein Client einen neuen HTTP/2-Stream startet und HEADERS- und CONTINUATION-Frames sendet, aber das Flag END_HEADERS niemals gesetzt wird, muss der Server einen unendlichen Header-Stream analysieren und im Speicher halten.
• In HTTP/1.1 schützen Headergrößenlimits sowie Request-/Header-Timeouts vor unendlichen Headern, aber bei vielen HTTP/2-Servern fehlen diese Schutzmaßnahmen oder sind fehlerhaft implementiert.

CPU-Verbrauch: der Fall Golang

• Golang ist ein Beispiel für CPU-Verbrauch durch CONTINUATION Flood und verwendet eine abstrakte Klasse namens http2MetaHeadersFrame, um HEADERS-Frames und CONTINUATION-Frames zu verarbeiten.
• Der HPACK-Decoder ist so eingestellt, dass er die Ausgabe von Headern stoppt, sobald das Headergrößenlimit erreicht ist; ohne das Flag END_HEADERS kehrt die Funktion jedoch nicht zurück und dekodiert weiter Header.

Speichermangel

• Speichermangel ist einer der schwerwiegendsten Fälle, da es Implementierungen gibt, die die Größe der mit CONTINUATION-Frames aufgebauten Headerliste nicht begrenzen.
• In Implementierungen ohne Header-Timeout kann bereits eine einzige HTTP/2-Verbindung den Server zum Absturz bringen.

Erreichbarer Assertion-Crash: Node.js (Sonderfall)

• Node.js verarbeitet einen unendlichen Stream von CONTINUATION-Frames korrekt, aber beim Abbruch der Verbindung während eines Header-Streams tritt ein Data-Race-Bug auf.
• Node.js verfolgt Speicherallokationen im Destruktor von Http2Session, und beim Verbindungsabbruch kann der Wert current_nghttp2_memory_ gleichzeitig aktualisiert werden, was zu einem Absturz führen kann.

Vergleich mit früheren HTTP/2-Schwachstellen

• In der Vergangenheit wurden mehrere HTTP/2-Schwachstellen gemeldet, und CONTINUATION Flood funktioniert auf andere Weise als frühere Schwachstellen.
• CONTINUATION Flood sendet nicht leere Header, sondern viele beliebige Header bis zum vom Server festgelegten Frame-Größenlimit.

Abschließende Anmerkungen

• HTTP/2-Traffic macht etwa 60 % des gesamten von Menschen erzeugten HTTP-Traffics aus; angesichts der Bedeutung der betroffenen Projekte war somit ein erheblicher Teil des Internets von einer leicht ausnutzbaren Schwachstelle betroffen.
• Falls diese Schwachstelle bereits in freier Wildbahn ausgenutzt wurde, wäre sie für Serveradministratoren ohne ausreichendes HTTP/2-Wissen sehr schwer zu debuggen gewesen.

Meinung von GN⁺

• Diese Schwachstelle kann die Verfügbarkeit von Servern massiv beeinträchtigen und ist besonders schwer nachzuverfolgen und abzuwehren, weil sie nicht in Logs erscheint.
• Serveradministratoren sollten regelmäßig Sicherheitsupdates einspielen und Traffic-Analysetools verwenden, um ungewöhnliche Muster zu erkennen.
• Solche Schwachstellen sollten die Cybersecurity-Community wachrütteln und die Bedeutung sichererer Protokolldesigns und Implementierungen unterstreichen.
• Kritisch betrachtet offenbart diese Schwachstelle grundlegende Designfehler in einem weit verbreiteten Protokoll, was Fragen zur Zuverlässigkeit der grundlegenden Internet-Infrastruktur aufwirft.
• Wer nicht über Fachwissen in diesem Bereich verfügt, dürfte Schwierigkeiten haben, eine derart komplexe Schwachstelle zu verstehen und darauf zu reagieren; deshalb sind mehr Sicherheitsbildung und Sensibilisierung nötig.

[GN⁺]

Hacker-News-Kommentare

• Dieses Problem kürzlich in Bandit behoben

  • Persönliche Erfahrung, dass dasselbe Problem vor einem Monat in Bandit behoben wurde.
  • Über einen Link wird die genaue Stelle im Code angegeben.
  • Aus Sicht des Implementierers ist dieses Problem sehr offensichtlich, und man ging davon aus, dass andere Implementierungen ebenfalls bereits Schutzmaßnahmen getroffen hätten.
  • Nach Prüfung von Dutzenden Implementierungen stellte sich jedoch heraus, dass selbst bei wichtigen HTTP/2-Servern solche Schutzvorrichtungen fehlten oder falsch implementiert waren.

• Kritik an der Entwicklungskultur

  • Es wird darauf hingewiesen, dass es problematisch ist, dass Entwickler sich zu sehr daran gewöhnt haben, dass Dinge automatisch dynamisch skalieren, und deshalb nicht darüber nachdenken, wie groß etwas werden kann.
  • Dieses Problem ist nicht auf HTTP/2 beschränkt, aber die Komplexität von HTTP/2 kann es weiter verschärfen.
  • Früher, zu Zeiten von HTTP/1.x, nutzte man Sprachen wie C und musste ständig auf die Verwaltung von Pufferlängen achten; Request-Header-Allokationen wurden nicht unbegrenzt ausgeweitet.

• Liste nicht betroffener Server/Reverse-Proxys

  • Liste der im vorherigen Artikel erwähnten nicht betroffenen Webserver und Reverse-Proxys.
  • Nginx, Jetty, HAProxy, NetScaler und Varnish sind nicht betroffen.

• Überlegungen zur Sicherheit von HTTP/1.1

  • Es wird erwähnt, dass unsere Website den ganzen Tag über Aufmerksamkeit bekommen hat.
  • Es wird die Frage aufgeworfen, ob bei geringem Traffic auf unserer Website die Nutzung von HTTP/1.1 sicherer wäre.

• Lob für den Autor

  • Lob dafür, dass der Autor mit Weitblick vorgeht, seine Entdeckungen verantwortungsvoll meldet und sie auf leicht verständliche Weise teilt.

• Erwähnung von Slowloris v2

  • Der Scherz, dass man dieses Problem, wenn man es langsam auslöst, "slowloris v2" nennen könnte.

• Hinweis auf einen Tippfehler

  • Der Tippfehler "serveral retries" wird amüsant gefunden.

• Kritische Sicht auf HTTP/2

  • Kritik daran, wie HTTP/2 als Transportschicht in ein Application-Layer-Protokoll hineingedrückt werden könne, um ein "Upgrade" zu erzwingen.