HTTP/2 : quatre failles découvertes, les correctifs disponibles

HTTP/2 : quatre failles découvertes, les correctifs disponibles

Ouf !

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

04/08/2016 5 minutes
25

HTTP/2 : quatre failles découvertes, les correctifs disponibles

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.

Failles HTT/2

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 :

Failles HTT/2

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 :

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

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

Fermer

Commentaires (25)


Effectivement corrigé dans Apache 2.4.20 publié en avril <img data-src=" />


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 <img data-src=" />








micdubs a écrit :



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 <img data-src=" />







Debian retroporte les MAJ de sécurité. Par contre, ca restera officiellement un apache 2.4.10 d’un point de vue fonctionnel



Ce protocole est utilisé ?








nost4r a écrit :



Ce protocole est utilisé ?





Ben… oui.<img data-src=" />



Par 9% des 10 millions sites les plus visités, ouais pas tant utilisé que ça.


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.


Donc très bien pour de la SOA et autres services quand ils sont dans un intranet :)


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.


Sympa l’article. Thk








nost4r a écrit :



Par 9% des 10 millions sites les plus visités, ouais pas tant utilisé que ça.



Il est utilisé quand même, faut du temps, tout comme l’ipv6. Et puis 9% des 10 millions de sites les plus visités, c’est déjà pas si mal, et ça sous-entend aussi qu’il doit être utilisé aussi sur au moins 9% des sites qui ne font pas partie des 10 millions de sites les plus visités, soit la (très) grande majorité du Web.



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 <img data-src=" />


Compte déjà tous les sites de Google. Facebook aussi. En terme de trafic, c’est déjà pas mal.


Sinon IIS c’est déjà une faille à lui-même.



<img data-src=" />


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. <img data-src=" />


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).








127.0.0.1 a écrit :



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. <img data-src=" />





Holala. Mets pas la charrue avant les boeufs, il y en a encore pour 10 ans de http1



Carrément. Ça tourne dans le noyau.








Ricard a écrit :



Holala. Mets pas la charrue avant les boeufs, il y en a encore pour 10 ans de http1







Dans 10 ans, je ne serai pas encore à la retraite. <img data-src=" />









127.0.0.1 a écrit :



Dans 10 ans, je ne serai pas encore à la retraite. <img data-src=" />





Dans 30 ans non plus. <img data-src=" />



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?


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…


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.