Des chercheurs présentent quatre failles de sécurité sur l'implémentation du protocole HTTP/2. Les éditeurs concernés (Apache, Microsoft, etc.) ont été prévenus en amont et des correctifs sont déjà en place depuis des mois.
Le protocole HTTP/2 est une évolution majeure du HTTP/1.x (ou simplement HTTP), qui a été finalisée en février de cette année. Le document RFC (numéroté 7540) a pour sa part été mis en ligne au mois de mai. Cela n'empêche pas les navigateurs de le prendre en charge depuis plusieurs mois maintenant, sans avoir attendu la version finale.
HTTP/2 : des améliorations intéressantes, mais aussi des risques liés à la nouveauté
Les avantages de cette mouture sont multiples, et l'une des caractéristiques techniques les plus intéressantes de HTTP/2 est certainement le multiplexage des requêtes (possibilité d'envoi par lots). Ce n'est pas tout et il est également question de la compression des en-têtes HTTP par exemple. De manière générale, ce protocole « permet une utilisation plus efficace des ressources disponibles et une réduction de la latence » explique l'Internet Engineering Task Force (IETF).
Beaucoup d'avantages donc, mais aussi des risques, comme à chaque fois qu'un nouveau protocole débarque et que des chercheurs ou pirates s'y intéressent de près. Lors de la conférence Black Hat 2016 qui se termine aujourd'hui à Las Vegas, des employés de la société Imperva (spécialisée dans la sécurité informatique) ont présenté quatre failles sur des implémentations du protocole HTTP/2 : Slow Read, HPACK Bomb, Dependency Cycle Attack et Stream Multiplexing Abuse.
Jouer la montre ou sur la compression des données
Dans le cas de Slow Read, l'attaquant fait appel à un client spécialement développé pour ouvrir de nombreuses connexions et les faire trainer en longueur dans le temps, surchargeant ainsi le serveur et finissant par provoquer un DoS (déni de service). Une approche identique à l'attaque Slowloris sur HTTP/1.x, mais amplifiée ici par le multiplexage. Elle porte l'identifiant CVE-2016-1546 et touche Apache 2.4.18, Jetty 9.3, IIS 10 et Nginx 1.9.9.
Vient ensuite une autre faille baptisée HPACK Bomb. Basée sur le principe de la bombe de décompression, cette attaque consiste à envoyer une toute petite quantité de données compressées, qui sera ensuite décompressée par le serveur via HPACK. C'est une des nouveautés de HTTP/2, un algorithme de compression auquel Stéphane Bortzmeyer a d'ailleurs consacré un billet de blog.
La sanction est alors un plantage du serveur dont la mémoire est rapidement saturée. Sont concernées les versions 1.7.0 et inférieures de nghttpd, ainsi que les moutures antérieures à la 2.0.2 et 1.12.10 de Wireshark.
Des boucles infinies et du multiplexage à outrance
Vient ensuite la brèche Dependency Cycle Attack. L'équipe de chercheurs explique qu'un pirate peut « tirer parti des mécanismes de contrôle des flux introduits dans HTTP/2 pour l'optimisation du réseau ». Un client spécialement conçu pour exploiter cette faille pourrait ainsi introduire des boucles infinies sur le serveur, ce qui n'est jamais une bonne idée.
De plus, à cause de certaines vulnérabilités dans la procédure de nettoyage de la mémoire vive de nghttp, un « attaquant peut causer un DoS ou même être en mesure d'exécuter du code arbitraire » expliquent les chercheurs. Apache en version 2.4.18 est touché, ainsi que les moutures 1.7.0 et plus anciennes de nghttpd.
Terminons enfin avec Stream Multiplexing Abuse, qui ne concerne qu'IIS 10 de Microsoft cette fois-ci. Cette faille exploite le multiplexage introduit avec HTTP/2 et une faiblesse du fichier HTTP.sys qui laissaient un client réutiliser un flux de connexion normalement fermé. Conséquence, un BSOD (écran bleu) sur le serveur. Microsoft a publié un bulletin de sécurité dédié en avril dernier.
Des correctifs déjà disponibles depuis des mois
Pour conclure leur étude, les chercheurs expliquent qu'ils ont réussi à trouver « une vulnérabilité exploitable dans presque tous les nouveaux composants du protocole HTTP/2 ». De plus, sur les cinq serveurs parmi les plus populaires, tous étaient sensibles à au moins une des attaques. Voici un résumé de la situation :
Dans tous les cas, Imperva précise que les éditeurs concernés (Microsoft, Apache, Nginx, Jetty, etc.) ont été contactés avant la publication de cette étude. Ils ont ainsi eu le temps de développer et de mettre en ligne les patchs nécessaires. Ceux-ci sont d'ailleurs souvent disponibles depuis des mois. Notez que d'autres serveurs HTTP peuvent être touchés par ces failles suivant l'implémentation de HTTP/2 qu'ils utilisent.
Malgré ces correctifs, , le détail de l'exploitation des failles n'avait simplement pas été rendu public. C'est désormais le cas dans ce document d'une vingtaine de pages :
