HPACK

🗓️ Contexte Publié le 2 juin 2026 sur le blog Calif (blog.calif.io), cet article présente la divulgation publique d’un exploit de déni de service distant baptisé HTTP/2 Bomb, découvert par l’IA Codex de OpenAI. La découverte a été réalisée par Quang Luong, avec confirmation par Jun Rong et Duc Phan. 🎯 Nature de l’attaque L’exploit chaîne deux techniques connues depuis une décennie : HPACK Indexed Reference Bomb : insertion d’un header dans la table dynamique HPACK (RFC 7541), puis émission de milliers de références indexées d’un seul octet. Chaque octet sur le réseau provoque une allocation mémoire côté serveur allant de ~70 octets (nginx, IIS, Pingora) à ~4 000 octets (Apache httpd, Envoy). HTTP/2 Window Stall : annonce d’une fenêtre de contrôle de flux à zéro octet, empêchant le serveur de libérer la mémoire allouée, avec envoi de trames WINDOW_UPDATE d’un octet pour maintenir la connexion ouverte indéfiniment. La nouveauté réside dans la source de l’amplification : contrairement aux bombes classiques qui stockent une grande valeur, ici le header est quasi vide et l’amplification provient du bookkeeping par entrée alloué par le serveur, contournant les limites de taille de header décodé. ...

🗓️ Contexte Publié le 3 juin 2026 sur BleepingComputer, cet article présente une nouvelle technique d’attaque par déni de service (DoS) nommée HTTP/2 Bomb, découverte par l’agent logiciel Codex d’OpenAI sous la direction de chercheurs de la société de sécurité offensive Calif. 🔍 Mécanisme de l’attaque L’attaque combine deux méthodes DoS HTTP/2 préexistantes : Amplification HPACK : un en-tête est inséré dans la table dynamique HPACK et référencé répétitivement via une représentation indexée compacte d’un seul octet. Un octet envoyé par l’attaquant peut provoquer des milliers d’octets d’allocation mémoire côté serveur (ratio jusqu’à 5 700:1 pour Envoy, 4 000:1 pour Apache httpd). Blocage de libération mémoire via flow-control HTTP/2 (style Slowloris) : en annonçant une fenêtre de contrôle de flux à zéro octet, le serveur ne peut jamais finaliser la réponse et continue d’envoyer des trames WINDOW_UPDATE pour éviter les timeouts. La mémoire allouée n’est jamais libérée. Cette combinaison permet à une seule machine sur une connexion 100 Mbps d’épuiser des dizaines de gigaoctets de RAM en quelques secondes. ...