XRING-Schwachstelle stürzt XQUIC-HTTP/3-Server mit 260 Byte ab

In der Bibliothek XQUIC – der von Alibaba veröffentlichten Open-Source-Implementierung der Protokolle QUIC und HTTP/3 – wurde eine Schwachstelle entdeckt, die es einem entfernten, nicht authentifizierten Client erlaubt, den Serverprozess durch das Senden von ungefähr 260 Byte vollständig legitimen QPACK-Traffics zum Absturz zu bringen. Die Schwachstelle mit dem Namen XRING betrifft alle XQUIC-Versionen bis einschließlich der aktuellen Version 1.9.4. Mit Stand 10. Juli ist kein Patch verfügbar, eine CVE-Kennung wurde nicht vergeben. Betreibern von auf XQUIC basierenden Servern wird dringend empfohlen, die dynamische QPACK-Tabelle umgehend zu deaktivieren, indem der Parameter SETTINGS_QPACK_MAX_TABLE_CAPACITY auf 0 gesetzt oder die Unterstützung für HTTP/3 vollständig abgeschaltet wird.

Mechanismus der Schwachstelle

Der Forscher Sébastien Ferré von FoxIO hat die Schwachstelle am 8. Juli öffentlich offengelegt. Die Ursache des Problems liegt in der Logik zur Erweiterung des Ringpuffers, den XQUIC zur Speicherung der dynamischen QPACK-Tabelle verwendet. Der Code befindet sich in der Datei xqc_ring_mem.c.

HTTP/3 verwendet QPACK, um wiederkehrende Header zu komprimieren. Der Client weist den Server über einen dedizierten Steuerkanal (encoder stream) an, die gemeinsame Tabelle zu vergrößern und ihre Größe anzupassen. Fordert der Client eine Vergrößerung der Tabelle an, reserviert XQUIC einen neuen, größeren Puffer und kopiert die Daten aus dem alten in den neuen. Der Kopiervorgang behandelt vier Szenarien, je nachdem, ob die Daten im alten Puffer, im neuen, in beiden oder in keinem „umgebrochen“ sind.

In einem dieser Szenarien berechnet der Code fälschlicherweise die Größe der „Tail“-Daten, indem er die Kapazität des neuen Puffers statt des alten heranzieht. Das führt zu einer groben Überschätzung der Länge des zu kopierenden Blocks. Nach Angaben des Forschers berechnet XQUIC beim Erweitern einer 64-Byte-Tabelle auf 65 Byte mit einem Schreibcursor nahe dem Ende des Puffers 70 Byte Tail-Daten statt der tatsächlichen 6.

Der überhöhte Wert wird in der weiteren Längenarithmetik für den Aufruf der Speicherkopie verwendet. Da die Länge im vorzeichenlosen Typ size_t gespeichert wird, führt das Subtrahieren der überhöhten Zahl von einem kleineren Wert zu einem ganzzahligen Unterlauf – die Länge „wrappt“ auf einen Wert nahe dem Maximum. Das Ergebnis ist ein Kopierversuch weit außerhalb des reservierten Speichers.

In der Testumgebung von FoxIO (Ubuntu, kompiliert mit _FORTIFY_SOURCE=2) erkannte der glibc-Schutzmechanismus die inkorrekte Länge und beendete den Prozess zwangsweise. Ohne diese Prüfung schreibt der Kopiervorgang Daten über das Ende des neuen Puffers hinaus. Der Forscher demonstrierte den Absturz, überprüfte jedoch nicht, ob sich die Schwachstelle zur Ausführung beliebigen Codes ausnutzen lässt.

Was XRING besonders gefährlich macht

Das entscheidende Merkmal dieser Schwachstelle ist, dass der Angriff weder Authentifizierung noch das Senden manipulierter Pakete erfordert. Alle im Angriff verwendeten Werte entsprechen der QPACK-Spezifikation. XQUIC gibt standardmäßig ein Limit für die dynamische Tabelle von 16 KiB vor; der Exploit fordert nacheinander 64 und 65 Byte an – beide Werte sind vollständig legitim. Der Client muss lediglich die Tabelle in einen bestimmten „Umbruchzustand“ versetzen, um den fehlerhaften Codepfad zu aktivieren.

Nach Angaben von FoxIO ist der Fehler seit der ersten öffentlichen Veröffentlichung von XQUIC im Januar 2022 vorhanden. Ein öffentlicher PoC-Exploit ist auf GitHub verfügbar. Zum Zeitpunkt der Offenlegung waren keine Ausnutzungen in realen Angriffen bekannt.

Betroffene Produkte und Umfang der Auswirkungen

XQUIC ist eine Bibliothek mit offenem Quellcode, und das Risiko beschränkt sich nicht auf die Infrastruktur von Alibaba. Nach Einschätzung der Forscher ist jeder Server verwundbar, der XQUIC zur Bereitstellung von HTTP/3 mit den Standard-QPACK-Einstellungen verwendet. Zu den betroffenen Produkten gehören:

• Alibaba XQUIC – alle Versionen bis einschließlich v1.9.4
• Tengine – der auf Nginx basierende Webserver von Alibaba, der nach Angaben von FoxIO die Cloud-Infrastruktur und das CDN des Unternehmens bedient

Es ist anzumerken, dass die Aussagen zum Umfang der Auswirkungen auf die Infrastruktur von Alibaba ausschließlich auf den Angaben des Forschers beruhen – eine offizielle Bestätigung durch den Hersteller liegt nicht vor.

Kontext: Reihe von Schwachstellen in HTTP/2 und HTTP/3

XRING fügt sich in einen bedenklichen Trend entfernbarer Denial-of-Service-Schwachstellen in HTTP/2- und HTTP/3-Stacks ein. Drei Wochen zuvor wurde eine Use-after-free-Schwachstelle im HTTP/3-Modul von NGINX (CVE-2026-42530) offengelegt, die über denselben QPACK encoder stream ausnutzbar ist – ein anderer Fehlertyp, aber eine identische Angriffsoberfläche. Im Februar hat HAProxy zwei Abstürze in QUIC behoben, von denen einer ebenfalls durch einen ganzzahligen Unterlauf ausgelöst wurde – denselben Fehlertyp wie bei XRING, dessen Ausnutzung hier jedoch ein manipuliertes Paket erforderte.

Der grundlegende Unterschied bei XRING: Für den Angriff genügt vollständig legitime Eingabe. Ein einziger arithmetischer Fehler – und der Server stellt den Dienst ein.

Empfehlungen zur Mitigation

Da es keinen offiziellen Patch gibt, müssen Betreiber von auf XQUIC basierenden Servern auf Workarounds zurückgreifen:

1. Dynamische QPACK-Tabelle deaktivieren – den Parameter SETTINGS_QPACK_MAX_TABLE_CAPACITY auf den Wert 0 setzen. Dies beseitigt den Angriffsvektor, erhöht jedoch das Volumen der übertragenen Header.
2. Unterstützung für HTTP/3 vollständig deaktivieren – eine drastische Maßnahme, die die Ausnutzung dieser Schwachstelle jedoch zuverlässig ausschließt.
3. Updates von XQUIC verfolgen – das Projekt-Repository regelmäßig auf die Veröffentlichung einer korrigierten Version prüfen.
4. Sicherstellen, dass _FORTIFY_SOURCE aktiviert ist – in Builds mit dieser Option fängt glibc fehlerhafte Kopiervorgänge ab und beendet den Prozess, wodurch ein mögliches Schreiben über das Pufferende hinaus verhindert wird. Das beseitigt den Denial-of-Service nicht, reduziert aber das Risiko einer weitergehenden Ausnutzung.

Offenlegungschronologie

Nach Angaben von FoxIO schickte das Unternehmen am 7. April eine Meldung an Alibaba über den in der Sicherheitsrichtlinie des Projekts beschriebenen Meldeweg (der eine Antwort innerhalb von drei Arbeitstagen zusichert) und sandte bis zum 9. Mai vier weitere Benachrichtigungen – auf keine davon ging eine Antwort ein. Daraufhin entschied sich der Forscher zur öffentlichen Offenlegung. Eine Bestätigung dieser Chronologie durch Alibaba liegt nicht vor.

Betreiber von Servern, die XQUIC oder Tengine mit HTTP/3-Unterstützung einsetzen, sollten die beschriebenen Workarounds umgehend umsetzen – mindestens den Parameter SETTINGS_QPACK_MAX_TABLE_CAPACITY=0 setzen. Angesichts eines verfügbaren öffentlichen PoC und fehlender Patches ist das Angriffsfenster geöffnet, während die Ausnutzung für einen Angreifer mit minimalem Aufwand verbunden ist: 260 Byte Traffic, die weder Authentifizierung noch eine Protokollverletzung erfordern.