Bombe HTTP / 2 : La vulnérabilité qui peut vider la RAM de vos serveurs en quelques secondes

Une nouvelle méthode de déni de service baptisée par ses découvreurs Bombe HTTP / 2 montre que la combinaison de techniques déjà connues peut devenir vulnérable aux serveurs modernes en quelques secondes: HPACK (compression d'en-têteHTTP / 2) est utilisé pour amplifier l'utilisation de la mémoire et le contrôle du flux HTTP / 2 est manipulé pour conserver indéfiniment cette mémoire assignée.

Selon le rapport technique publié par les chercheurs de Calif et disponible sur leur blog, une seule machine domestique avec une connexion de 100 Mbps peut forcer des serveurs tels qu'Envoy, Apache httpd, NGINX ou IIS à consommer des dizaines de gigaoctets de RAM en secondes; les expériences jouées par l'équipe montrent des rapports d'amplification extrêmes - jusqu'à 5 700 octets consommés par chaque octet envoyé dans le cas d'Envoy - et des drains de 32-64 Go en moins d'une minute dans des configurations par défaut. Plus de détails et le contexte de la découverte sont dans la déclaration de Calif: https: / / blog.calif.io / p / codex-découverte-a-hidden-http2-bomb.

La première « jambe » de l'attaque exploite comment HPACK maintient une table dynamique d'entrées d'en-tête : l'attaquant insère une petite entrée et la référence à plusieurs reprises en utilisant sa représentation indexée d'un octet, ce qui fait un minimum de données réseau cause beaucoup de mémoire interne par comptabilité et structures que le serveur réserve pour chaque en-tête. Le deuxième "paw" profite du mécanisme de contrôle de flux HTTP / 2 : le client annonce une fenêtre à octets zéro et empêche la réponse d'être terminée, tandis que le serveur envoie un petit WINDOW _ UPDATE éclate ou maintient l'état de connexion pour éviter le temps d'attente ; le résultat est que la mémoire réservée n'est pas libérée.

Cette approche évite les mesures traditionnelles qui limitent la taille totale des en-têtes décodés parce que les en-têtes utilisés dans l'exploitation sont intentionnellement petits; l'amplification se produit dans la gestion interne par en-tête et dans les structures liées à l'état d'écoulement. La spécification HPACK reconnaît les risques d'amplification de la mémoire, mais les chercheurs soulignent qu'elle ne traite pas adéquatement de l'effet combiné à une rétention indéfinie par le contrôle du débit : l'interaction entre les sous-systèmes est la cause de l'impact catastrophique.

Calif déjà publié des tests de concept dans GitHub, de sorte que les opérateurs et les équipements de sécurité doivent agir avec prudence et hâte: https: / / github.com / califio / publications / arborescence / main / MADBugs / http2-bomb. Il est également recommandé d'examiner la spécification HPACK pour comprendre l'origine du problème technique : https: / / httpwg.org / specs / rfc7541.html.

Certains fournisseurs et projets ont déjà lancé des mesures d'atténuation: NGINX a introduit la directive _ en-têtes max dans la version 1.29.8 et Apache corrigé mod _ http2 dans la version indiquée par l'équipe; cependant, à la date du présent rapport, il n'y avait pas de correctifs officiels pour toutes les implémentations concernées, y compris certaines versions du moteur Envoy, Microsoft IIS ou Cloudflare Pingora. Lorsque aucun correctif n'est disponible, des recommandations pragmatiques sont de désactiver HTTP / 2 si possible, ou de placer un proxy inverse / CDN qui filtre et limite le nombre d'en-têtes et de contrôles de flux avant qu'ils n'atteignent le serveur d'accueil.

Pour les opérations et les équipes d'intervention en cas d'incident, les actions spécifiques qui devraient être priorisées comprennent l'application immédiate des correctifs disponibles, l'examen de l'exposition des paramètres HTTP / 2 dans l'infrastructure publique, permettant des limites de connexion strictes (nombre maximal d'en-têtes et de flux simultanés), et la garantie que les proxys ou les WAF appliquent des seuils durs. En outre, la fixation de limites de ressources par processus / worker et règles du noyau (OOM-killer et cgroups) aide à contenir les dommages lorsque la mémoire commence à croître.

En termes de détection, les premiers indicateurs sont des modèles inhabituels de « demi-ouvert » ou avec des fenêtres à flux zéro persistantes, une augmentation rapide de l'utilisation de la mémoire par les processus HTTP / 2 et un grand nombre d'entrées répétées dans les compteurs d'en-tête décodés. La surveillance des paramètres de connexion, des temps de réponse et des compteurs internes du module HTTP / 2 de chaque serveur facilite l'identification des tentatives d'exploitation avant que la machine ne devienne inutilisable.

Cette découverte a également une dimension communautaire: elle a été découverte avec l'aide d'un agent logiciel coordonné (Codex) par des chercheurs humains, qui met en évidence comment les outils d'IA peuvent accélérer l'identification de vecteurs complexes mais aussi comment leur utilisation nécessite des normes de divulgation responsables. L'exposé technique complet sera rendu public lors de la conférence sur la sécurité de l'IA dans le monde réel; dans l'intervalle, l'existence du PoC exige des mesures comme si le risque était réel et exploitable.

Si votre service sert le trafic public, prioriser un inventaire rapide des composants qui exposent HTTP / 2, mettre à jour NGINX / Apache le cas échéant et, si vous ne pouvez pas vous garer immédiatement, placer un CDN / proxy qui validera et limitera le nombre d'en-têtes par connexion. Documentez les mesures d'atténuation et les tests dans votre jeu d'incident: la vitesse de détection et l'application des limites de connexion sont la différence entre un incident mineur et une baisse complète du service.

Enfin, la nature du problème rappelle que la sécurité des protocoles modernes dépend non seulement des spécifications individuelles mais de leurs interactions dans les implémentations réelles ; les équipes responsables de l'infrastructure doivent intégrer des tests de stress spécifiques HTTP / 2 dans leurs validations d'architecture défensive et de sécurité.