SICHERHEITS-CHECK / LONDON (IT BOLTWISE) – Eine einzelne Fehlberechnung in der QUIC- und HTTP/3-Bibliothek XQUIC lässt sich offenbar ohne Anmeldung und ohne speziell „kaputten“ Verkehr auslösen: Ein kurzer, regelkonformer QPACK-Stream kann den Serverprozess zum Absturz bringen. Betroffen ist laut Sicherheitsmeldung jede XQUIC-Version bis 1.9.4 – und damit nicht nur der Alibaba-Stack, sondern auch zahlreiche Integrationen bei anderen Web- und Proxy-Implementierungen. Bis ein Fix bereitsteht, empfehlen Betreiber, QPACK dynamische Tabellen auszuschalten oder HTTP/3 testweise komplett abzuschalten. Für Unternehmen ist das vor allem deshalb kritisch, weil die Angriffsfläche über den Header-Kompressions-Mechanismus in die Standard-HTTP/3-Pipeline ragt.
Im HTTP/3-Ökosystem ist eine neue, besonders unangenehme Sicherheitslücke sichtbar geworden: Der Fehler trägt den Namen XRING und steckt in XQUIC, der QUIC- und HTTP/3-Bibliothek von Alibaba. Laut der Meldung reicht bereits ein kurzer Burst an vollständig gültigem Traffic, um den Serverprozess aus dem Tritt zu bringen. Entscheidend ist dabei der Angriffsmodus: Der Client benötigt keine Anmeldung und muss keine Pakete „absichtlich kaputt“ senden. Die Auslöserdaten liegen in der Größenordnung von etwa 260 Bytes QPACK-Verkehr, also genau jener Komponente, die HTTP/3 nutzt, um wiederkehrende Header effizient zu komprimieren. Bislang gibt es laut Stand der Veröffentlichung keinen gepatchten Release und auch noch keine zugeordnete CVE.
Technisch lässt sich die Logik hinter dem Absturz relativ klar nachzeichnen. HTTP/3 ersetzt die Header-Compression aus HTTP/2 durch QPACK, um parallele Streams und eine getrennte Steuerkanal-Architektur zu unterstützen. QPACK führt eine dynamische Tabelle ein, die zwischen Client und Server über einen dedizierten Kontrollmechanismus aufgebaut und umgebaut wird. In XQUIC wird die Byte-Repräsentation dieser Tabelle in einem Ringbuffer verwaltet: Ein fester Speicherbereich, dessen Inhalt bei Erreichen des Endes „umschlägt“, sodass neue Daten an den Anfang geschrieben werden können. Wenn der Client die dynamische Tabelle wachsen lässt, muss XQUIC den Ringbuffer vergrößern und den bestehenden Inhalt korrekt in den neuen Speicherbereich kopieren.
Genau hier entsteht das Problem: Beim Kopieren gibt es mehrere Fälle, je nachdem ob der Datenwrap im alten Buffer, im neuen Buffer, in beiden oder in keinem Fall auftritt. In einer dieser Verzweigungen wird die Größe des verbleibenden Tail-Bereichs fälschlich gegen die Kapazität des neuen, größeren Buffers statt gegen die Kapazität des alten Buffers bemessen. Dadurch rechnet die Implementation deutlich zu viel „übrig gebliebene“ Daten an. Das wird gefährlich, weil die Kopierlänge später als unsigned Wert (typisch: size_t) in die Speicheroperation fließt. Unterläuft dieser Wert, „wrappt“ er auf einen sehr großen Zahlenwert. Ohne zusätzliche Schutzmechanismen führt das dazu, dass ein memcpy-ähnlicher Copy außerhalb der vorgesehenen Speichergrenzen schreibt – vom alten Buffer aus über das Ende des neuen Buffers hinaus.
Dass es sich in der Praxis zunächst als Crash zeigt, liegt am konkreten Laufzeitumfeld. In einem Release-Build unter Ubuntu 26.04 soll der glibc-Schutz _FORTIFY_SOURCE=2 die fehlerhafte Kopierlänge erkannt und den Prozess abgewürgt haben. Ohne diesen Check wäre jedoch laut Analyse eher mit speicherbezogener Korruption statt nur mit einem kontrollierten Stopp zu rechnen. Wichtig ist dabei die Angriffsqualität aus Meldesicht: Die Werte verletzen QPACK- und Protokollregeln nicht. XQUIC signalisiert standardmäßig eine dynamische Tabelle von 16 KiB; der Payload fordert dann aber bewusst sehr kleine Tabellenfenster an und treibt die Größenänderung von 64 auf 65 Byte. Um den problematischen Branch sicher zu triggern, muss der Client die Tabelle in eine exakte Wrapped-Layout-Konstellation bringen, was aber offenbar ohne „malformed packet“-Strategie auskommt.
Für Betreiber und Anbieter ist die Marktwirkung klar: Das Risiko endet nicht beim reinen Alibaba-Stack. Da XQUIC Open Source ist, können andere HTTP/3-Server die Bibliothek direkt einbinden oder indirekt über abgeleitete Implementierungen nutzen. Genannt wird unter anderem Tengine, der von Alibaba entwickelte Webserver auf Basis von Nginx-ähnlicher Codebasis. Dort soll HTTP/3 über XQUIC ausgeliefert werden, und zwar in Umgebungen, die über Taobao und Alipay bis hin zu Cloud- und CDN-Strukturen reichen. Entsprechend können mehrere Produktlinien und Infrastrukturschichten gleichzeitig betroffen sein, wenn sie HTTP/3 mit Standard-QPACK-Konfiguration aktiv haben. Die Meldung ordnet den Ursprung außerdem zeitlich ein: Der Fehler soll seit der ersten öffentlichen Veröffentlichung von XQUIC im Januar 2022 existieren und ist offenbar in jeder Version bis einschließlich v1.9.4 nachweisbar.
Der Vergleich mit früheren HTTP/2- und HTTP/3-Vorfällen zeigt, warum diese Klasse von Bugs gerade jetzt so ernst genommen wird. Drei Wochen zuvor wurde berichtet, dass es in NGINXs HTTP/3-Modul ebenfalls zu einem Remote-Absturz kommen kann, wenn eine nicht authentifizierte Anfrage die gleiche Angriffsurface über den QPACK-Encoder-Stream erreicht; dabei ging es um eine andere Bug-Kategorie als XRING, aber wieder um das Prinzip, dass ein „normaler“ Protokollkanal weitreichende Auswirkungen hat. Im Juni war zudem ein Vorfall in HTTP/2 bekannt, der eine Denial-of-Service-Fähigkeit durch das Ausnutzen von HPACK vermittelte; HPACK ist QPACKs Vorgängermechanismus für Header-Kompression. Und im Februar wurden bei HAProxy zwei QUIC-Abstürze gepatcht, darunter ein Integer-Underflow während Token-Validierung, der vom Typ her an XRING erinnert, allerdings zusätzliche Paketmanipulation erforderte. Genau diese Differenz – „legaler Input“ gegen „malformed packet“ – ist in der Praxis der Unterschied zwischen theoretischer Erreichbarkeit und unkompliziertem Remote-Trigger.
Was die Sicherheitsorganisation betrifft, bleibt ein zentraler Punkt offen: Ob und wann ein Fix sowie eine CVE folgen. Die Meldung schildert, dass der Forscher den Hersteller über die Projekt-Sicherheitsrichtlinie per E-Mail am 7. April informiert haben will, mit mehreren Nachfassaktionen bis zum 9. Mai. Danach wurde der Fehler öffentlich gemacht, offenbar ohne Antwort innerhalb der angekündigten Zeitspanne. In der Zwischenzeit versucht die Community, konkrete Details zu klären: ob bereits ein Patch existiert, ob eine CVE geplant ist und ob die Angriffe bereits in der Wildnis vorkommen. Gleichzeitig bleibt festzuhalten, dass zwar ein Crash gezeigt wurde, aber keine belastbare Evidenz für ausnutzbaren Code Execution im Feld vorliegt. Für die meisten Enterprise-Teams bedeutet das trotzdem „sofortige Risikoreduktion“, weil Crashs in produktiven HTTP/3-Setups häufig als Verfügbarkeitsvorfall zählen.
Bis ein Fix verfügbar ist, werden zwei pragmatische Gegenmaßnahmen empfohlen. Zum einen können Betreiber SETTINGS_QPACK_MAX_TABLE_CAPACITY auf 0 setzen, wodurch die dynamische Tabelle deaktiviert wird und damit die Angriffslogik, die auf Ringbuffer-Resizes und Tail-Berechnungen zielt, aus dem Takt gerät. Zum anderen steht als „Brechstangen“-Variante die Deaktivierung von HTTP/3 an sich im Raum. In der Praxis sollten Security- und Plattformteams die Auswirkungen gegeneinander abwägen: QPACK-Deaktivierung kann zwar weiterhin HTTP/3 unterstützen, aber die Header-Kompressions-Effizienz reduzieren; HTTP/3-Abschaltung reduziert die Angriffsfläche vollständig, kann jedoch Latenz- und Performanceprofile gegenüber HTTP/2 verändern. Entscheidend ist zudem die Betriebsrealität: Load Balancer, Reverse Proxies, Webserver und CDN-Edge-Services müssen gemeinsam betrachtet werden, weil die gleiche Bibliothek in mehreren Schichten landen kann.
Ausblickend dürfte die Entwicklung vor allem zwei Spuren nehmen. Erstens werden Anbieter und Maintainer die QPACK- und Ringbuffer-Verwaltung bei HTTP/3-Implementierungen genauer automatisiert testen müssen: Fehler dieser Art entstehen oft durch seltene Kombinationsfälle von Wrapped-Layouts und unterschätzte unsigned-Arithmetik. Zweitens wird das Monitoring für unbeabsichtigte Crash-Signaturen und „graceful degradation“-Pfadsteuerung an Bedeutung gewinnen, damit ein einzelner Remote-Trigger nicht automatisch ganze Worker-Pools oder Instanzen destabilisiert. Für Entwickler entsteht dadurch auch eine Chancenperspektive: Wer HTTP/3-Stack-Komponenten nachweisbar in seiner eigenen Release- und Fuzzing-Pipeline validiert, reduziert nicht nur den XRING-Fall, sondern auch die Wahrscheinlichkeit weiterer ähnlicher Rechenfehler im selben Attack-Surface. Langfristig ist damit zu rechnen, dass Hardening in der Protokollschicht stärker in den Vordergrund rückt – und dass Teams ihre HTTP/3-Rollouts noch stärker an Sicherheitsgateways koppeln.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "XRING: Ungepatchte XQUIC-Fehlberechnung kann HTTP/3-Server per Legal-Traffic crashen" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "XRING: Ungepatchte XQUIC-Fehlberechnung kann HTTP/3-Server per Legal-Traffic crashen" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »XRING: Ungepatchte XQUIC-Fehlberechnung kann HTTP/3-Server per Legal-Traffic crashen« bei Google Deutschland suchen, bei Bing oder Google News!