XRING Der XQUIC-Ausfall, der Server mit nur Hunderten von Verkehrsbytes vervollständigen kann

Eine falsche mathematische Überprüfung auf XQUIC, die Implementierung von QUIC und HTTP / 3 von Alibaba gefördert, ermöglicht es einem legitimen Remote-Client, den Server-Prozess mit einem sehr kurzen Traffic-Blow unter dem Protokoll blockiert werden. Der Forscher Sébastien Féry, von FoxIO, machte am 8. Juli das Scheitern unter dem Spitznamen XRING bekannt; nach seinem Bericht sind keine fehlerhaften Pakete oder Authentifizierung erforderlich: einige hundert normale QPACK-Verkehrsbytes reichen aus, um den Prozess abzubrechen.

Die technische Wurzel des Ausfalls liegt in der Verwaltung der QPACK dynamischer Tisch, der Mechanismus, der es vermeidet, wiederholt identische Header in HTTP / 3 zu senden. XQUIC hält diesen Tisch in einem Ringpuffer (Ringpuffer) Und wenn Sie es erweitern, kopieren Sie die alten Daten in eine neue. Ein Zweig dieses Codes berechnet die Größe des Schwanzes, um zu bewegen, wenn die Daten "wrap" das Ende des Puffers; der Overcount wird in einer Untermenge über eine unmarkierte ganze verwendet, die durch Hinterschneidung und Herstellung einer gigantischen Länge für eine Speicherkopie endet, mit dem resultierenden off-limits Schreiben und dem Zusammenbruch des Prozesses in Umgebungen mit Sicherheitskontrollen in Laufzeit.

Dieser Fehler ist besonders beunruhigend, weil XQUIC Open Source ist und in Drittanbieter-Server und -Proxies integriert ist: jedes Projekt, das die Bibliothek nutzt und HTTP / 3 mit den Standard-QPACK-Einstellungen ausgibt, kann beeinträchtigt werden. FoxIO identifiziert Tengine, den Alibaba Nginx-basierten Webserver, als eines der Produktionsprodukte, die XQUIC verwendet und Angriffe empfangen konnte, die sich auf hochraffic Portale auswirken.

Bisher gibt es keinen offiziellen Patch oder veröffentlicht CVE (Stand am 10. Juli nach der Untersuchung). Inzwischen gibt es eine operative Minderung: SETTINGS _ QPACK _ MAX _ TABELLE _ CAPACITY bis 0 die dynamische Tabelle von QPACK deaktivieren oder, falls nicht möglich, HTTP / 3 Unterstützung deaktivieren ganz vorne. Beide Optionen entfernen die von XRING ausgenutzte Angriffsfläche, obwohl die zweite die Kosten für den Verlust von HTTP / 3 Vorteile hat.

Neben Konfigurationsmodifikationen sollten die Geräte zusätzliche defensive Maßnahmen berücksichtigen: Erstellung und Implementierung von Härtungsservern (ASLR, PIE, Stack-Kanäle und Compiler-Konstruktionen, die Schutze wie _ FORTIFY _ SOURCE umfassen), Segmente und HTTP / 3 Prozesse enthalten und neue QUIC / UDP-Verbindungen anwenden, um die Wahrscheinlichkeit von Bursts zu reduzieren, die Fehler verursachen. Die einfachste und schnellste Maßnahme ist in vielen industriellen Einsatzbereichen, den QUIC / HTTP / 3 Traffic auf Perimeter- oder CDN-Ebene zu blockieren oder zu filtern, bis eine offizielle Korrektur verfügbar ist.

Identifizieren Sie, ob es verwundbar ist, indem Sie die Anwesenheit von XQUIC in den Binaries und Versionen überprüfen: das Hauptprojekt ist in GitHub und dort können Sie die Geschichte und die Starts überprüfen ( https: / / github.com / alibaba / xquic) Um den Kopfverdichtungsmechanismus zu verstehen, der durch diese Art von Fehlern ausgesetzt ist, sollte auf die QPACK-Spezifikation des IETF verwiesen werden ( https: / / datatacker.ietf.org / doc / html / rfc9204), die erklärt, wie die dynamische Tabelle und der Encoder Stream Koordinatenaktualisierungen.

Der XRING-Fall wird in eine Reihe neuer Schwachstellen auf komprimierten Header-Oberflächen eingefügt: HTTP / 2 und frühere QUIC / HTTP / 3 Implementierungen haben Fehler gezeigt, die entfernte DoS oder Speicherfehler erlauben. Die Kombination von gültigen Protokolleingängen, einem einzigen arithmetischen Fehler und Code, der die Speicherkopie nicht ausreichend schützt, zeigt, wie eine falsche Zeile einen massiven Einfluss auf die Verfügbarkeit haben kann.

Für Infrastrukturbetreiber ist die sofortige praktische Empfehlung, Konfigurationen und Bereitstellungen zu überprüfen: deaktivieren Sie die dynamische Tabelle von QPACK oder HTTP / 3, gelten Regeln in der CDN / Proxy, um QUIC-Verkehr zu blockieren, wenn möglich und überwachen plötzliche Crash-Vorfälle in HTTP / 3 Prozessen. Beachten Sie auch die Feststellung in der Verwaltung von Patches und abonnieren Sie die Sicherheitslisten der Projekte, um den offiziellen Fix anzuwenden, sobald es veröffentlicht wird. Wenn Tengine verwendet wird oder eine XQUIC Gabel, kontaktieren Sie den Lieferanten oder das Paket Wartungsteam und erfordern dringende Aktualisierung; die Open Source erleichtert die Überprüfung, aber auch die Patching-Verantwortung.

Schließlich unterstreicht diese Art des Ausfalls die Notwendigkeit, tiefgreifende Verteidigungen anzuwenden: sichere Compilationspolitiken, kopforientierte Fuzzing-Tests, Code-Audits in kritischen Speicherkopie-Bereichen und eine Bereitstellungsstrategie, die die Fähigkeit beinhaltet, Protokolle zu deaktivieren, ohne Dienste zu brechen. Der Software-Anbieter und -betreiber sollten koordiniert werden, um sicherzustellen, dass sie bei der Ankunft der Patches mit der Geschwindigkeit eingesetzt werden, die durch eine Sicherheitsanfälligkeit erforderlich ist, die eine Denialisierung des Dienstes von voll legitimen Kunden ermöglicht.