Vulnérabilité dans les implémentations du protocole HTTP/2, facilitant les attaques par déni de service (DoS)

Une nouvelle technique d'attaque sur les implémentations du protocole HTTP/2 a été présentée, simplifiant la conduite d'attaques visant à provoquer des dénis de service par épuisement des ressources serveur. La vulnérabilité a reçu le nom de code MadeYouReset et permet, via des manipulations de frames de contrôle HTTP/2, d'inonder le serveur avec un grand nombre de requêtes en contournant les limitations imposées.

Le problème réside dans le fait que le client peut créer un nombre très élevé de flux traités simultanément, indépendamment de la limite SETTINGS_MAX_CONCURRENT_STREAMS, en réinitialisant chaque flux à son début. Ce type de réinitialisation signifie que, pour envoyer une nouvelle requête dans la connexion HTTP/2 établie, le client n'est pas obligé d'attendre la réponse de de serveurs et peut immédiatement engager un grand flot continu de requêtes, dans la mesure où la bande passante le permet.

Le client ne dépend plus des délais entre l'envoi de la requête et la réception de la réponse (RTT, round-trip time) et peut mener une attaque avec des coûts minimaux, alors que le serveur continue de dépenser des ressources pour traiter les requêtes entrantes. Par exemple, le serveur alloue des structures de données pour de nouveaux flux, analyse les requêtes, décompresse les en-têtes et associe les URL aux ressources. Lors d'attaques sur des proxy inverses, l'attaque peut s'étendre aux backends vers lesquels le proxy aura redirigé la requête avant sa réinitialisation.

La vulnérabilité rappelle un problème connu auparavant, Rapid Reset (CVE-2023-44487), et est causée par un écart entre la logique de réinitialisation des flux, définie dans la spécification du protocole HTTP/2, et celle mise en œuvre dans les produits finaux. La spécification prévoit la possibilité de réinitialiser un flux par le client et le serveur à tout moment, mais dans de nombreuses implémentations HTTP/2,serveurs après ce type de réinitialisation, la requête continue d'être traitée. La principale différence avec la nouvelle attaque est que la réinitialisation du traitement de la requête est effectuée à l'initiative du serveur, et non par l'envoi d'une frame avec le drapeau RST_STREAM par le client.

Le réinitialisation à l'initiative du serveur se produit lorsque des requêtes incorrectes sont reçues, mais ces requêtes sont immédiatement rejetées sans début de traitement complet et sans passer au backend. Pour obtenir un cycle complet de traitement de la requête, un attaquant peut d'abord envoyer une requête HTTP correcte, puis transmettre une séquence incorrecte de cadres de contrôle HTTP/2. Une telle activité amènera le serveur à commencer à traiter la requête, mais ensuite, en raison d'une erreur lors du traitement des cadres suivants, il réinitialisera le flux (mettant le flux avec la requête correcte dans un état RST_STREAM).

Le problème a été confirmé dans les serveurs HTTP Apache Tomcat, Netty, Eclipse Jetty, Fastly, Varnish, Lighttpd et Zephyr RTOS. Le problème se manifeste également sur les sites web et services serveur de Mozilla. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed et HAProxy ne sont pas affectés par le problème. L'état de la vulnérabilité dans nginx n'est pas déterminé.

Source : opennet.ru