Résumé

  • HTTP/2 Rapid Reset exploitait la possibilité de créer puis d’annuler rapidement des flux, de façon à faire supporter au serveur une charge disproportionnée par rapport au nombre de flux actifs.
  • La divulgation coordonnée, les correctifs des éditeurs et les discussions de l’IETF ont constitué des réponses différentes. Aucun de ces éléments, pris isolément, ne prouve que tous les systèmes déployés étaient réparés.

Le point de départ est une asymétrie de coût. Un client HTTP/2 peut ouvrir un flux, provoquer le traitement initial d’une requête, puis envoyer presque immédiatement une trame RST_STREAM pour l’annuler. HTTP/2 prévoit cette trame et son rôle dans la terminaison d’un flux est défini par la spécification publiée en 2022, la RFC 9113. Cette RFC est antérieure à la divulgation publique de CVE-2023-44487 : elle décrit le comportement protocolaire, mais ne constitue pas une analyse rétrospective de l’attaque. Lire la RFC 9113

Le défaut opérationnel ne tient donc pas à une simple commande oubliée. Il apparaît lorsque la création et l’annulation de flux déclenchent suffisamment de travail côté serveur avant que la demande d’annulation ne réduise les ressources effectivement consommées. Le dossier CVE décrit une condition de déni de service touchant plusieurs implémentations HTTP/2, associée à des réinitialisations répétées et à l’épuisement des ressources. Consulter la fiche NVD Le programme CVE attribue à ce problème l’identifiant CVE-2023-44487 et renvoie vers des sources techniques et des avis de sécurité. Voir l’enregistrement CVE

Le signal ne venait pas d’un seul propriétaire

La première difficulté de responsabilité est institutionnelle. Le problème concernait une surface de protocole maintenue dans un processus de normalisation, mais son effet dépendait de logiciels distincts, de versions prises en charge et de chemins de service administrés par des organisations différentes. La CERT Coordination Center a décrit l’attaque comme une ouverture et une réinitialisation rapides de flux, avec un travail serveur potentiellement disproportionné. Elle a également recommandé des mises à jour des éditeurs et des contrôles propres aux implémentations, tels que des limites de flux, de débit ou de réinitialisation lorsqu’elles sont disponibles. Lire l’avis de la CERT/CC

Cela sépare déjà trois affirmations souvent confondues : le comportement existe dans la surface autorisée par le protocole ; une implémentation donnée l’expose d’une manière exploitable ; un opérateur donné a corrigé ou contenu cette exposition. La première affirmation relève du texte normatif. La deuxième exige une analyse de produit. La troisième exige une preuve de déploiement.

Les observations publiées par Google, Cloudflare et Akamai rendent le mécanisme intelligible, mais leurs mesures restent liées à leurs propres réseaux et méthodes. La publication de Google Security décrit également l’exploitation observée et la coordination de la réponse. Lire la publication de Google Security Google décrit la création et l’annulation répétées de flux ainsi que des attaques distribuées observées en 2023. Lire l’analyse de Google Cloud Cloudflare explique comment les signaux de création et de réinitialisation pouvaient produire beaucoup de travail tout en maintenant un faible nombre de flux actifs, et décrit des attaques de grande ampleur dans son environnement. Lire l’analyse de Cloudflare Akamai présente de son côté la détection et l’atténuation à la périphérie, avant que le trafic n’atteigne les systèmes d’origine. Lire l’analyse d’Akamai

Ces récits concordent sur le mécanisme général, mais ils ne mesurent pas la prévalence mondiale. Une attaque observée par un fournisseur n’est pas une estimation de la proportion de serveurs encore exposés. Les chiffres de taille, les seuils de détection et l’efficacité des protections doivent donc être attribués à l’environnement qui les a produits.

De la divulgation à la correction normative

La divulgation coordonnée a fourni un point de passage entre la découverte, les éditeurs et les opérateurs. Mais elle n’a pas transformé automatiquement une recommandation en état uniforme du réseau. Les documents publics de l’IETF montrent ensuite un autre type de travail : le groupe HTTP a examiné la manière dont le texte de HTTP/2 devait être révisé après la divulgation. Le projet HTTP/2bis et ses discussions permettent de suivre les propositions et les arbitrages, tout en rappelant qu’un Internet-Draft est un travail en cours. Lire le projet HTTP/2bis

L’issue consacrée à Rapid Reset rend visible la discussion sur les réponses possibles au niveau du protocole. Elle peut aider à distinguer une modification normative d’une mesure défensive propre à un serveur ou à un fournisseur. Mais une discussion GitHub ne vaut pas, à elle seule, texte final ni preuve d’adoption par les implémentations. Suivre la discussion du groupe HTTP

Cette séquence est importante pour comprendre ce que l’IETF contrôle réellement. Le processus peut documenter le comportement, organiser l’examen technique et produire ou réviser une spécification. Il ne peut pas, par la publication d’un texte, certifier l’état de chaque bibliothèque, proxy, équilibreur, passerelle ou service qui implémente HTTP/2. La légitimité de la coordination normative ne doit pas être confondue avec une autorité d’exploitation sur les réseaux.

Le correctif devient concret au niveau du produit

Les traces de réparation deviennent plus précises lorsqu’elles sont examinées dans les chaînes de versions. La documentation d’Envoy signale des corrections et des changements de configuration liés à Rapid Reset dans une ligne de versions donnée. Elle montre pourquoi il faut identifier la version réellement exécutée, et non seulement le nom du logiciel. Consulter l’historique Envoy

Les informations de NGINX distinguent également l’impact sur certains produits et les mesures de mitigation disponibles. Un conseil propre à un produit ne peut pas être généralisé à toutes les piles HTTP/2. Lire les informations NGINX

Le suivi Red Hat ajoute une complication fréquente : une distribution peut intégrer un correctif rétroporté sans modifier le numéro de version amont de façon évidente. Le statut d’un paquet doit donc être vérifié pour le produit, la version, l’architecture et le canal de mise à jour effectivement utilisés. Consulter le suivi Red Hat

La distinction est opérationnelle. “Le fournisseur a publié un correctif” est une information sur la chaîne de maintenance. “Le paquet installé contient le correctif” est une information sur la chaîne de distribution. “Le service exposé utilise ce paquet et les contrôles attendus” est une information sur le déploiement. Enfin, “les signaux de surveillance ne montrent plus le comportement dangereux sur les chemins concernés” est une information de vérification. Les quatre niveaux ne sont pas interchangeables.

Ce que prouve — et ne prouve pas — la priorisation

Le catalogue Known Exploited Vulnerabilities de la CISA est un outil de priorisation pour les vulnérabilités confirmées comme exploitées dans la nature. Si CVE-2023-44487 figure dans l’instantané consulté, cette présence appuie une décision de traitement prioritaire ; elle ne mesure ni la proportion de l’Internet restant vulnérable ni l’exposition de chaque opérateur. Consulter le catalogue KEV

La limite est essentielle pour les conseils d’administration et les responsables de continuité. Une échéance de traitement réglementaire ou administrative peut prouver qu’un risque a été classé urgent pour un périmètre donné. Elle ne prouve pas que la correction est installée partout, que les systèmes hérités ont disparu, ou que les protections périphériques couvrent chaque origine directe.

Le dossier de fermeture doit suivre le chemin de service

La réparation durable est donc un dossier de preuves, pas un seul événement. Il devrait relier au moins : la version ou le paquet déployé ; l’avis de l’éditeur applicable ; les réglages de limites et de débit ; les chemins d’exposition, y compris les équipements qui ne passent pas par une même protection ; les journaux de détection ; les tests de comportement ; et les exceptions acceptées par le responsable du risque.

Ce dossier ne permet pas nécessairement de calculer une prévalence publique. Il permet cependant de répondre à une question plus utile : pour chaque service qui doit rester accessible, qui a vérifié quelle propriété, à quelle date, avec quel résultat, et quelle condition déclencherait une nouvelle action ?

La réponse institutionnelle à Rapid Reset est ainsi distribuée. Le texte de l’IETF encadre un langage commun ; les chercheurs et les fournisseurs décrivent le mécanisme ; la CERT/CC et les agences de sécurité accélèrent la coordination ; les éditeurs publient des correctifs ou des contrôles ; les distributions les intègrent parfois par rétroportage ; les opérateurs les déploient ; les systèmes de mesure cherchent les résidus. Aucun maillon ne peut se substituer entièrement aux autres.

La conclusion doit rester bornée. Les sources examinées établissent la mécanique de l’attaque, la divulgation coordonnée, des réponses de produits et une discussion de révision du protocole. Elles n’établissent pas le pourcentage universel de systèmes encore vulnérables après divulgation, ni le déploiement effectif chez chaque opérateur. La publication d’une correction est donc un jalon nécessaire, mais la clôture de l’exposition est une affirmation distincte qui exige des preuves jusqu’au dernier chemin opérationnel.