Forschende des Unternehmens Calif haben eine Beschreibung einer neuen Remote-Attacke vom Typ Denial-of-Service (DoS) veröffentlicht, die den Namen HTTP/2 Bomb erhalten hat. Nach Angaben der Forschenden tritt das verwundbare Verhalten in den Standardkonfigurationen von HTTP/2 auf Servern mit NGINX, Apache HTTPD, Microsoft IIS, Envoy und Cloudflare Pingora auf. Die Technik kombiniert zwei bekannte Ansätze – eine Kompressionsbombe und das Offenhalten von Verbindungen im Stil von Slowloris –, um den Arbeitsspeicher des Servers zu erschöpfen. Patches stehen derzeit nur für NGINX und Apache HTTPD zur Verfügung; für die übrigen Produkte lagen zum Zeitpunkt der Veröffentlichung keine Fixes vor. Administratoren von Servern mit aktiviertem HTTP/2 wird empfohlen, umgehend zu prüfen, ob sie betroffen sind, und Maßnahmen zur Mitigation zu ergreifen.
Mechanismus der Attacke
Der Angriff zielt auf HPACK – den Algorithmus zur Header-Kompression im Protokoll HTTP/2, der Huffman-Codierung einsetzt und laut Cloudflare im Mittel eine Reduktion der Headergröße um etwa 30 Prozent erreicht. HPACK wurde als gegenüber Angriffen der Klasse CRIME resistente Alternative zur allgemeinen Header-Kompression entworfen.
Der entscheidende Unterschied der HTTP/2 Bomb zur klassischen HPACK Bomb (CVE-2016-6581, 2016 offengelegt) besteht in der Quelle der Verstärkung. Die klassische Variante platzierte einen großen Wert in der HPACK-Tabelle und referenzierte ihn mehrfach, was zur Einführung von Schutzlimits für die Gesamtgröße der dekodierten Header führte. Der neue Ansatz funktioniert anders: Die Header sind nahezu leer, und die Verstärkung entsteht durch die internen Datenstrukturen, die der Server für jeden Eintrag in der Tabelle allokiert. Das Limit für die Größe der dekodierten Daten greift nicht, da faktisch nichts zu dekodieren ist.
Die zweite Komponente der Attacke ist das Offenhalten der Verbindung. Der Angreifer setzt ein Flow-Control-Window von null, wodurch der Server den allokierten Speicher nicht freigeben kann. Dieses Vorgehen ähnelt der Slowloris-Attacke, die zahlreiche HTTP-Verbindungen offen hält und so die Ressourcen des Servers auf Anwendungsebene erschöpft.
Die Forschenden verweisen außerdem auf Zusammenhänge mit einer Reihe früher bekannter Schwachstellen in HTTP/2-Implementierungen: CVE-2016-8740 (DoS über speziell gestaltete CONTINUATION-Frames in Apache HTTP Server) und CVE-2016-1546 (Erschöpfung von Worker-Threads in einer HTTP/2-Verbindung von Apache).
Bewertung der Auswirkungen
Laut Angaben von Calif, die mit Vorbehalt als Informationen aus einer Einzelquelle ohne unabhängige Bestätigung zu betrachten sind, kann ein einzelner Client mit einer 100-Mbit/s-Anbindung einen verwundbaren Server innerhalb weniger Sekunden außer Betrieb setzen. Es wird außerdem behauptet, dass ein einzelner Client auf Apache HTTPD und Envoy in rund 20 Sekunden bis zu 32 GB Serverspeicher belegen und halten kann.
Wie die Forschenden betonen, besteht das grundlegende Problem darin, dass die HTTP/2-Spezifikation das Speicherrisiko ausschließlich über den Verstärkungsfaktor bewertet, während der kritische Faktor die Haltezeit des allokierten Speichers ist. Ein Faktor von 70:1 ist harmlos, wenn der Speicher nach Abschluss der Anfrage freigegeben wird, wird jedoch zum Angriffsvektor, wenn das Protokoll es dem Client praktisch ohne Kosten erlaubt, die Verbindung offen zu halten.
Potentiell betroffen sind alle Organisationen, die die genannten Webserver mit HTTP/2 in der Standardkonfiguration einsetzen. Am stärksten gefährdet sind öffentlich erreichbare Server, die direkte HTTP/2-Verbindungen von Clients verarbeiten. Wichtig ist der Hinweis: Aktive Ausnutzung in realen Angriffen wurde bislang nicht beobachtet, keiner der zugehörigen CVEs ist im CISA-KEV-Katalog verzeichnet. Der Bedrohungsstatus entspricht derzeit dem Vorliegen einer öffentlich dokumentierten PoC-Technik.
Empfehlungen zur Mitigation
Verfügbare Schutzmaßnahmen unterscheiden sich je nach eingesetzter Server-Software:
- Apache HTTPD – Aktualisierung des Moduls mod_http2 auf Version v2.0.41, die den Fix enthält. Ist ein Update nicht möglich, sollte HTTP/2 deaktiviert werden, indem die Direktive
Protocols http/1.1gesetzt wird. - NGINX – nach Angaben der Forschenden ist ein Fix in Version 1.29.8+ verfügbar, die die Direktive
max_headersmit dem Standardwert 1000 einführt. Ist ein Update nicht möglich, wird empfohlen, HTTP/2 mit der Direktivehttp2 off;zu deaktivieren. Zu beachten ist, dass diese Versionsangaben zu NGINX aus einer Einzelquelle stammen und nicht durch ein offizielles NGINX-Bulletin bestätigt sind. - Microsoft IIS, Envoy, Cloudflare Pingora – zum Zeitpunkt der Veröffentlichung der Untersuchung lagen keine Patches vor. Für diese Produkte bleibt als einzige Maßnahme die Deaktivierung von HTTP/2, sofern dies für die Infrastruktur vertretbar ist, oder die Begrenzung der Anzahl gleichzeitiger HTTP/2-Verbindungen auf Ebene des Load-Balancers oder WAF.
Zusätzlich wird empfohlen:
- Einen Audit der Webserver-Konfigurationen hinsichtlich der Nutzung von HTTP/2 als Standard durchzuführen.
- Ein Monitoring für anomalen Speicherverbrauch der Webserver-Prozesse zu etablieren.
- Die maximale Anzahl gleichzeitiger HTTP/2-Verbindungen pro IP-Adresse zu begrenzen.
- Das Erscheinen offizieller Security-Bulletins der Hersteller der betroffenen Produkte zu verfolgen.
Organisationen, die Apache HTTPD und NGINX mit aktiviertem HTTP/2 betreiben, sollten die verfügbaren Updates mit Priorität einspielen – mod_http2 v2.0.41 für Apache und Version 1.29.8+ für NGINX. Für Server mit Microsoft IIS, Envoy und Cloudflare Pingora ist zu prüfen, ob eine temporäre Deaktivierung von HTTP/2 oder die Einführung kompensierender Kontrollen auf Ebene der Netzwerkinfrastruktur bis zur Veröffentlichung offizieller Patches möglich ist. Da die Technik Standardverhalten ausnutzt und keine Authentifizierung erfordert, stellt ein Zögern bei der Mitigation ein reales Risiko für die Verfügbarkeit öffentlicher Services dar.
