Une faille QPACK peut faire planter des serveurs HTTP/3 à distance, sans authentification, via une amplification mémoire de 4 000.

Une nouvelle faille QPACK met en danger de nombreux serveurs web compatibles HTTP/3. La société de sécurité FoxIO l’a rendue publique. Elle a également diffusé un code de démonstration fonctionnel. Ainsi, un attaquant distant, sans aucun compte, peut faire tomber un serveur avec une seule connexion.

Le principe est simple. D’abord, l’attaquant envoie un petit volume d’en-têtes HTTP compressés. Ensuite, une fois décompressés, ils occupent bien plus de place en mémoire. L’amplification peut ainsi atteindre 4 000 fois le volume reçu.

Une faille QPACK révélée par FoxIO

QPACK est le mécanisme de compression des en-têtes utilisé par HTTP/3. Il remplit le même rôle que HPACK dans HTTP/2. Son but est donc de réduire la quantité de données échangées entre un client et un serveur.

FoxIO a identifié plusieurs défauts dans la manière dont ces en-têtes compressés sont traités. Par ailleurs, l’entreprise a publié un code de preuve de concept. Autrement dit, la menace n’est plus seulement théorique. N’importe quel acteur malveillant peut désormais tester l’attaque.

Le point le plus inquiétant tient aux prérequis. En effet, l’attaquant n’a pas besoin de s’authentifier. Il lui suffit d’établir une connexion vers un serveur HTTP/3 exposé sur Internet. En outre, une seule connexion suffit à provoquer l’incident.

Comment fonctionne l’amplification mémoire

La compression permet de représenter de longs en-têtes par de courtes références. Le serveur doit ensuite reconstruire ces en-têtes pour les traiter. C’est cette étape qui pose problème.

Un petit lot de données compressées peut décrire un ensemble d’en-têtes très volumineux. Le serveur le développe alors en mémoire. Ainsi, quelques octets reçus se transforment en une charge énorme. Le rapport peut aller jusqu’à 4 000 pour 1.

Ce type de déséquilibre est classique dans les attaques de déni de service. L’attaquant dépense très peu de bande passante. En revanche, la victime consomme une quantité disproportionnée de ressources. Selon FoxIO, cette consommation suffit à épuiser la mémoire d’un serveur dans sa configuration par défaut.

Par conséquent, un attaquant n’a pas besoin de botnet massif. Une machine isolée et une connexion unique peuvent suffire. Le coût de l’attaque reste donc très faible.

Pourquoi les réglages par défaut comptent

De nombreux administrateurs déploient HTTP/3 sans modifier les paramètres de base. Or ces valeurs par défaut ne prévoient pas toujours de limites strictes. Un serveur sans plafond mémoire par connexion devient donc une cible facile.

Quels risques pour les serveurs HTTP/3 ?

L’effet principal est le plantage du service. En effet, lorsque la mémoire est saturée, le système peut arrêter le processus du serveur web. Dans certains cas, il peut aussi devenir instable. Les sites et les API concernés deviennent alors indisponibles.

Cependant, l’impact dépend de plusieurs éléments. D’abord, HTTP/3 doit être activé et accessible depuis Internet. Ensuite, l’implémentation du serveur doit être vulnérable. Enfin, la quantité de mémoire disponible et les limites configurées jouent un rôle.

Les informations rendues publiques ne détaillent pas ici la liste des produits touchés. Il convient donc de rester prudent. Les équipes doivent vérifier leurs propres piles logicielles et suivre les avis des éditeurs. De plus, la publication du code de démonstration réduit le délai avant d’éventuelles attaques réelles.

Les services très exposés sont les premiers concernés. Cela inclut notamment les sites à fort trafic, les passerelles API et les répartiteurs de charge. En effet, une interruption y a des conséquences immédiates sur l’activité.

Recommandations face à la faille QPACK

Aucune correction universelle n’est mentionnée dans les éléments disponibles. Plusieurs mesures de prudence s’imposent néanmoins. Elles limitent le risque en attendant les correctifs.

• Inventorier les serveurs, proxys et répartiteurs de charge qui exposent HTTP/3.
• Surveiller les avis de sécurité des éditeurs et appliquer les mises à jour dès leur publication.
• Limiter la mémoire allouée à chaque connexion et la taille des tables d’en-têtes, lorsque le logiciel le permet.
• Superviser la consommation mémoire et configurer des alertes en cas de pic soudain.
• Envisager de désactiver temporairement HTTP/3 sur les services critiques, si aucune protection n’est disponible.

Désactiver HTTP/3 reste une solution de repli. Les clients reviennent alors à HTTP/2 ou HTTP/1.1. Toutefois, le service demeure accessible, même si les performances peuvent légèrement baisser.

Ce qu’il faut retenir

• FoxIO a divulgué de nouveaux défauts touchant QPACK, la compression d’en-têtes de HTTP/3.
• Ainsi, un attaquant distant et non authentifié peut faire planter un serveur avec une seule connexion.
• En effet, l’amplification mémoire atteint jusqu’à 4 000 fois le volume envoyé.
• De plus, un code de preuve de concept est déjà public.
• Enfin, les administrateurs doivent identifier leurs serveurs HTTP/3, appliquer les correctifs et fixer des limites mémoire.

Source : New QPACK Flaws Can Crash HTTP/3 Servers, Trigger Up to 4,000-Fold Memory Amplification