HTTP/2 : quatre failles découvertes, les correctifs disponibles
Ouf !
Le 04 août 2016 à 15h00
5 min
Internet
Internet
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 :
HTTP/2 : quatre failles découvertes, les correctifs disponibles
-
HTTP/2 : des améliorations intéressantes, mais aussi des risques liés à la nouveauté
-
Jouer la montre ou sur la compression des données
-
Des boucles infinies et du multiplexage à outrance
-
Des correctifs déjà disponibles depuis des mois
Commentaires (23)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 04/08/2016 à 15h13
Effectivement corrigé dans Apache 2.4.20 publié en avril " />
Le 04/08/2016 à 15h24
Question bête, debian 8 embarque la version 2.4.10 d’Apache, elle ne sera donc jamais mise à jour ?
Merci par avance pour la réponse " />
Le 04/08/2016 à 15h26
Le 04/08/2016 à 15h46
Ce protocole est utilisé ?
Le 04/08/2016 à 15h48
Le 04/08/2016 à 15h51
Par 9% des 10 millions sites les plus visités, ouais pas tant utilisé que ça.
Le 04/08/2016 à 16h00
Le protocole http/2 ne peut actuellement être utilisé que via une connexion HTTPS. Avec let’encrypt les sites si tu en train de passer à HTTPS en masse, passer en http/2 sera l’étape suivante
Retour d’expérience : j’ai passé plusieurs sites en http/2 : on sent la difference sur des gros sites single page avec angularJS.
Le 04/08/2016 à 16h10
Donc très bien pour de la SOA et autres services quand ils sont dans un intranet :)
Le 04/08/2016 à 16h11
Un titre bien pompeux pour rien de très inquiétant au final.
Il ne s’agit que d’attaques de type DOS coté serveur, comme on en trouve des dizaines chaque année. En fait elles ne seraient pas liées à HTTP/2, elles seraient passées totalement inaperçues.
Le 04/08/2016 à 16h31
Sympa l’article. Thk
Le 04/08/2016 à 16h58
Le 04/08/2016 à 17h02
Oui mais en l’occurrence, les failles ne concerne que le module http2 introduit dans la 2.4.18. Donc pas de MàJ dans ce cas " />
Le 04/08/2016 à 17h05
Compte déjà tous les sites de Google. Facebook aussi. En terme de trafic, c’est déjà pas mal.
Le 04/08/2016 à 17h27
Sinon IIS c’est déjà une faille à lui-même.
" />
Le 04/08/2016 à 17h46
Je regrette déjà HTTP/1. On peut s’écrire un mini serveur en 5 lignes de code et, grace à son protocole en texte clair, on peut tester un round request/response avec un simple telnet dans un shell.
Avec HTTP/2, tout est en binaire, avec des entêtes compressées avec des algos maisons, et la plupart des sites demandent un accès par liaison sécurisée…
Vivement la retraite que j’ai pas a débugger ce genre de machinerie complexe. " />
Le 04/08/2016 à 18h47
Petite précision : HTTP/2 peut également fonctionner sans couche TLS, ça n’est pas imposé par le protocole, simplement les navigateurs ayant implémenté HTTP/2 ont restreint son utilisation aux communications sécurisées.
Personnellement je trouve ça aussi absurde que le fait d’avoir un gros message d’avertissement sur les communications sécurisées mais non vérifiées (celles avec certificat auto-signé) alors que rien n’apparaît pour les commnications en clair (http classique).
Le 04/08/2016 à 19h07
Le 04/08/2016 à 19h54
Carrément. Ça tourne dans le noyau.
Le 04/08/2016 à 23h13
Le 05/08/2016 à 08h00
Le 05/08/2016 à 09h09
Merci pour l’article, par contre il n’y aurait pas un glissement du terme “faille”?
Les failles décrites ici s’apparentent à mon sens d’avantage à des “bug” (mis à part celle qui permet l’exécution de code arbitraire) qu’à de véritables failles. Par exemple le coup du DDOS, de la bombe de décompression ou du BSOD sont d’avantage l’exploitation des limites de la machine plutôt que des “failles”.
Sinon dans ce cas, tout bugs peut-être considéré comme une faille?
Le 05/08/2016 à 11h08
une faille est nécessairement un bug (au sens fonctionnement non prévu du logiciel qui met en péril la sécurité de celui-ci - touche la disponibilité, confidentialité, intégrité) mais tout bug n’est pas forcément une faille (au sens exploitable autrement que par le logiciel sur lui-même… un truc qui apparatrait rose alors qu’il devrait être orange, c’est un bug mais tout le monde s’en fout)
ça ne reste que mon interprétation…
Le 05/08/2016 à 13h48
Elle est très juste. La sécurité, c’est une question de disponibilité, d’intégrité, de non-répudiation et de confidentialité.
Un bug qui touche un de ces points est une faille. Un bug qui impacte un aspect fonctionnel de l’application n’est pas forcément une faille.