- Oui. La défaillance de XQUIC qui peut renverser des serveurs avec seulement des centaines d'octets de trafic

Une mauvaise vérification mathématique sur XQUIC, l'implémentation de QUIC et HTTP / 3 promue par Alibaba, permet à un client distant légitime de faire bloquer le processus du serveur avec un trafic très court sous le protocole. Le chercheur Sébastien Féry, de FoxIO, a rendu public l'échec le 8 juillet sous le surnom XRING ; selon son rapport, aucun paquet malformé ou authentification n'est requis : quelques centaines d'octets de trafic QPACK normaux suffisent pour faire tomber le processus.

La racine technique de l'échec est dans la gestion de la Table dynamique QPACK, le mécanisme qui évite d'envoyer à plusieurs reprises des en-têtes identiques en HTTP / 3. XQUIC garde cette table dans une tampon circulaire ( tampon de roulement) Et quand vous l'agrandissez, vous copiez les anciennes données dans une nouvelle. Une branche de ce code calcule mal la taille de la queue pour se déplacer lorsque les données "enroulent" l'extrémité du tampon; le surcompte est utilisé dans un sous-ensemble sur un entier non marqué qui se termine par une sous-cotation et produisant une longueur gigantesque pour une copie de mémoire, avec l'écriture hors limites résultante et l'effondrement du processus dans des environnements avec des contrôles de sécurité dans le temps de fonctionnement.

Cet échec est particulièrement inquiétant car XQUIC est open source et est incorporé dans des serveurs tiers et des mandataires : tout projet utilisant la bibliothèque et exposant HTTP / 3 avec les paramètres QPACK par défaut peut être affecté. FoxIO identifie Tengine, le serveur web Alibaba Nginx, comme l'un des produits de production que XQUIC utilise et pourrait recevoir des attaques qui affectent les portails à trafic élevé.

Pour l'instant, il n'y a pas de patch officiel ou de CVE publié (statut au 10 juillet selon l'enquête). Entre-temps, il y a des mesures d'atténuation opérationnelles : DÉFINITIONS _ QPACK _ MAX _ TABLEAU _ CAPACITÉ À 0 pour désactiver la table dynamique de QPACK ou, si cela n'est pas possible, désactiver le support HTTP / 3 complètement devant. Les deux options suppriment la surface d'attaque exploitée par XRING, bien que la seconde ait le coût de perdre HTTP / 3 avantages.

Outre les modifications de configuration, l'équipement devrait envisager d'autres mesures défensives : compiler et implémenter des serveurs de durcissement (ASLR, PIE, canaris de piles et constructions de compilateurs qui incluent des protections telles que _ FORTIFY _ SOURCE), segmenter et contenir des processus HTTP / 3 et appliquer des limites de débit aux nouvelles connexions QUIC / UDP pour réduire la probabilité de ruptures. Dans de nombreux déploiements industriels, la mesure la plus facile et la plus rapide est de bloquer ou de filtrer le trafic QUIC / HTTP / 3 au niveau du périmètre ou du CDN jusqu'à ce qu'une correction officielle soit disponible.

Identifiez si elle est vulnérable commence par vérifier la présence de XQUIC dans les binaires et les versions: le projet principal est en GitHub et là vous pouvez vérifier l'historique et les lancements ( https: / / github.com / alibaba / xquic). Pour comprendre le mécanisme de compression d'en-tête qui est exposé par ce type d'erreur, il convient de se référer à la spécification QPACK de l'IETF ( https: / / datatacker.ietf.org / doc / html / rfc9204) qui explique comment la table dynamique et le flux d'encodeur coordonnent les mises à jour.

Le cas XRING est inséré dans une série de vulnérabilités récentes sur les surfaces d'en-tête compressées : les implémentations HTTP / 2 et précédentes QUIC / HTTP / 3 ont montré des erreurs qui permettent des corruptions DoS ou mémoire distantes. La combinaison d'entrées de protocole valides, d'une seule erreur arithmétique et d'un code qui ne protège pas adéquatement la copie mémoire montre comment une mauvaise ligne peut avoir un impact massif sur la disponibilité.

Pour les gestionnaires d'infrastructure, la recommandation pratique immédiate est de revoir les configurations et les déploiements : désactiver la table dynamique de QPACK ou HTTP / 3, appliquer des règles dans le CDN / proxy pour bloquer le trafic QUIC si possible et surveiller les incidents de crash soudain dans les processus HTTP / 3. De plus, notez la conclusion dans la gestion des correctifs et abonnez-vous aux listes de sécurité des projets impliqués pour appliquer le correctif officiel dès sa publication. Si Tengine est utilisé ou une fourche XQUIC, communiquez avec le fournisseur ou l'équipe de maintenance du colis et demandez une mise à jour urgente; l'open source facilite l'examen mais disperse également la responsabilité de patching.

Enfin, et au-delà du court terme, ce type d'échec souligne la nécessité d'appliquer des défenses en profondeur : des politiques de compilation sécurisées, des tests de flous orientés vers la tête, des audits de code dans les zones critiques de copie de mémoire et une stratégie de déploiement qui inclut la capacité de désactiver les protocoles sans casser les services. Le fournisseur de logiciels et les opérateurs devraient être coordonnés pour s'assurer que, lorsque les correctifs arrivent, ils sont déployés avec la vitesse requise par une vulnérabilité qui permet de refuser le service à des clients pleinement légitimes.