Inondation de `CONTINUATION` HTTP/2 : détails techniques

Vulnérabilité d’inondation de CONTINUATION HTTP/2 : détails techniques

• L’inondation de CONTINUATION est une catégorie de vulnérabilités découverte dans plusieurs implémentations du protocole HTTP/2, et elle représente une menace plus grave que l’attaque Rapid Reset.
• Les conséquences de l’attaque vont du crash du serveur à la dégradation des performances, et les requêtes d’attaque n’apparaissent pas dans les journaux d’accès HTTP.

Préface

• En octobre 2023, l’auteur a découvert l’attaque HTTP/2 Rapid Reset et a décidé de commencer des recherches sous l’angle de l’analyse de sécurité de HTTP/2.

Brève introduction à HTTP/2

• La principale différence entre HTTP/1.1 et HTTP/2 est que le second est un protocole binaire, dans lequel le client et le serveur échangent des frames au lieu de lignes de texte.
• Une explication des frames HEADERS et CONTINUATION est nécessaire.

Frame HEADERS

• La frame HEADERS est utilisée pour transmettre les en-têtes HTTP des requêtes et des réponses, et compresse les données d’en-tête à l’aide de l’algorithme d’encodage HPACK.
• Des flags comme END_HEADERS et END_STREAM peuvent être définis sur la frame.

Frame CONTINUATION

• La frame CONTINUATION est très similaire à la frame HEADERS, mais elle ne possède que le flag END_HEADERS ; lorsque ce flag est défini, cela signifie que le flux d’en-têtes est terminé.

Vulnérabilité d’inondation de CONTINUATION

• Si un client démarre un nouveau flux HTTP/2 et envoie des frames HEADERS et CONTINUATION sans que le flag END_HEADERS ne soit jamais défini, le serveur doit analyser un flux d’en-têtes infini et le stocker en mémoire.
• En HTTP/1.1, les limites de taille des en-têtes et les timeouts de requête/en-tête protègent contre des en-têtes infinis, mais dans de nombreux serveurs HTTP/2, ces protections sont absentes ou mal implémentées.

Consommation CPU : cas de Golang

• Golang est un exemple de consommation CPU causée par l’inondation de CONTINUATION ; il utilise une classe abstraite appelée http2MetaHeadersFrame pour traiter les frames HEADERS et CONTINUATION.
• Le décodeur HPACK est configuré pour arrêter l’émission des en-têtes lorsqu’il atteint la limite de taille des en-têtes, mais en l’absence du flag END_HEADERS, la fonction ne retourne pas et continue à décoder les en-têtes.

Manque de mémoire

• Le manque de mémoire est l’un des cas les plus graves : certaines implémentations ne limitent pas la taille de la liste d’en-têtes construite à l’aide des frames CONTINUATION.
• Dans les implémentations sans timeout des en-têtes, une seule connexion HTTP/2 peut suffire à faire planter le serveur.

Crash par assertion atteignable : Node.js (cas particulier)

• Node.js gère correctement un flux infini de frames CONTINUATION, mais un bug de concurrence de données se produit lorsque la connexion est interrompue au milieu du flux d’en-têtes.
• Node.js suit les allocations mémoire dans le destructeur de Http2Session, et lorsque la connexion est coupée, la valeur current_nghttp2_memory_ est mise à jour simultanément, ce qui peut provoquer un crash.

Comparaison avec les vulnérabilités HTTP/2 précédentes

• Plusieurs vulnérabilités HTTP/2 ont déjà été signalées par le passé, et l’inondation de CONTINUATION fonctionne différemment des vulnérabilités précédentes.
• Au lieu d’envoyer des en-têtes vides, l’inondation de CONTINUATION envoie de nombreux en-têtes arbitraires, jusqu’à la limite de taille de frame définie par le serveur.

Remarques finales

• Le trafic HTTP/2 représente environ 60 % de tout le trafic HTTP humain ; compte tenu de l’importance des projets affectés, une part significative d’Internet a été touchée par une vulnérabilité facilement exploitable.
• Si cette vulnérabilité avait été exploitée dans la nature, elle aurait été très difficile à déboguer pour les administrateurs de serveurs sans connaissances appropriées sur HTTP/2.

L’avis de GN⁺

• Cette vulnérabilité peut gravement nuire à la disponibilité des serveurs et, comme elle n’est pas consignée dans les logs, elle est difficile à tracer et à contrer.
• Les administrateurs de serveurs doivent appliquer régulièrement les mises à jour de sécurité et utiliser des outils d’analyse du trafic pour détecter les schémas anormaux.
• Ce type de vulnérabilité doit alerter la communauté de la cybersécurité et souligne l’importance d’une conception et d’implémentations de protocole plus sûres.
• D’un point de vue critique, cette vulnérabilité révèle un défaut fondamental de conception dans un protocole largement utilisé, ce qui soulève des questions de fiabilité concernant l’infrastructure de base d’Internet.
• À moins d’être un expert disposant de connaissances dans le domaine concerné, il peut être difficile de comprendre et de gérer une vulnérabilité aussi complexe ; il est donc nécessaire de renforcer la formation et la sensibilisation à la sécurité.

[GN⁺]

Commentaires Hacker News

• Ce problème a récemment été corrigé dans Bandit

  • Expérience personnelle indiquant que le même problème a été corrigé dans Bandit il y a un mois.
  • Fournit un emplacement précis du code via un lien.
  • Du point de vue de l’implémenteur, ce problème paraissait très évident, et l’on pensait que d’autres implémentations avaient déjà mis en place des protections.
  • Cependant, après avoir vérifié des dizaines d’implémentations, il s’est avéré que même de grands serveurs HTTP/2 n’avaient pas ce type de protection, ou l’avaient mal implémenté.

• Critique de la culture de développement

  • Il est souligné que le problème vient d’une culture où les développeurs sont trop habitués à ce que les choses s’étendent automatiquement et dynamiquement, sans réfléchir à la taille qu’elles peuvent atteindre.
  • Ce problème ne se limite pas à HTTP/2, mais la complexité de HTTP/2 peut l’aggraver.
  • À l’époque de HTTP/1.x, avec des langages comme le C, il fallait constamment faire attention à la gestion de la taille des buffers, et on n’étendait pas indéfiniment l’allocation des en-têtes de requête.

• Liste des serveurs / reverse proxies non affectés

  • Liste des serveurs web et reverse proxies non affectés mentionnés dans l’article précédent.
  • Nginx, Jetty, HAProxy, NetScaler et Varnish ne sont pas affectés.

• Réflexion sur la sécurité de HTTP/1.1

  • Mention que notre site a été sous les projecteurs toute la journée.
  • La question est posée de savoir si, lorsque le trafic de notre site est faible, il serait plus sûr d’utiliser HTTP/1.1.

• Éloges envers l’auteur

  • Éloges pour l’auteur, qui a abordé le sujet avec une vision large, a signalé ses découvertes de manière responsable et les a partagées de façon facile à lire.

• Mention de Slowloris v2

  • Plaisanterie disant que si l’on provoque ce problème lentement, on pourrait l’appeler « slowloris v2 ».

• Mention d’une faute de frappe

  • Trouve amusante la faute de frappe « serveral retries ».

• Regard critique sur HTTP/2

  • Critique sur la manière dont HTTP/2 a pu être « imposé » comme couche de transport pour une « mise à niveau » d’un protocole de couche applicative.