Si vous utilisez le protocole HTTP au quotidien, alors vous utilisez régulièrement deux de ses méthodes GET et POST. Cependant, HTTP a d'autres méthodes, et la méthode OPTIONS est l'une d'entre elles. Elle permet de demander à un serveur quelles sont les autres méthodes HTTP qu'il supporte. Le serveur répond donc avec l'en-tête « Allow » qui donne une liste séparée par des virgules de méthodes prises en charge.
En scannant les sites du Top 1 million d'Alexa, le chercheur a découvert quelque chose d'étrange. Beaucoup de serveurs ont envoyé un en-tête Allow avec ce qui ressemblait à des données corrompues. Les réponses des serveurs étaient similaires à ce qui suit :
Code : | Sélectionner tout |
1 2 3 4 5 | Allow: ,GET,,,POST,OPTIONS,HEAD,, Allow: POST,OPTIONS,,HEAD,:09:44 GMT Allow: GET,HEAD,OPTIONS,,HEAD,,HEAD,,HEAD,, HEAD,,HEAD,,HEAD,,HEAD,POST,,HEAD,, HEAD,!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" Allow: GET,HEAD,OPTIONS,=write HTTP/1.0,HEAD,,HEAD,POST,,HEAD,TRACE |
Le développeur d'Apache Jacob Champion a mené des investigations sur le problème et a pu comprendre ce qui se passait. Apache prend en charge une directive de configuration Limit qui permet de restreindre l'accès à certaines méthodes HTTP à un utilisateur spécifique. Et la corruption se produit si l'on définit la directive Limit dans un fichier .htaccess pour une méthode HTTP qui n'est pas enregistrée globalement dans le serveur. « La définition d'une directive Limit pour toute méthode HTTP non valide dans un fichier .htaccess provoque une erreur dans la construction de l'en-tête Allow », explique le chercheur.
La faille a été baptisée Optionsbleed étant donné sa similitude avec Heartbleed, Yahoobleed et d'autres vulnérabilités qui provoquent des fuites de mémoire. Mais Optionsbleed serait moins dangereuse que les autres « bleeds ». D’après l’équipe Threatpost de Kaspersky, le risque semble plus pressant uniquement dans les environnements partagés, et seulement si le logiciel exécute une certaine configuration rare.
Yann Ylavic, membre du Comité de gestion de projet de serveur HTTP Apache, a déclaré à Threatpost que le risque est limité et que seulement quelques octets sont divulgués dans les configurations affectées. Il n'y a eu aucune indication que des données sensibles sont divulguées, dit-il, avant d’ajouter qu’un patch serait déjà prêt. « Le correctif a été validé dans notre dépôt ('upstream') et sera dans une nouvelle version sous peu », a déclaré Ylavic.
Il a reconnu que la vulnérabilité n'est pas difficile à reproduire sur les systèmes concernés. Cependant, la grande majorité des systèmes ne semble pas vulnérable vu qu'il s'agit d'une configuration rare. « La grande majorité des systèmes n'utilisent pas de configuration affectée et faire en sorte qu'une configuration soit affectée nécessite un accès en écriture à la configuration. Dans certains environnements partagés, un utilisateur avec un accès en écriture pourrait provoquer une modification de la configuration sans la connaissance d'autres utilisateurs », a déclaré Ylavic. « Cela peut être atténué déjà sur les systèmes non patchés, en définissant certaines directives dans la configuration principale qui n'est pas accessible en écriture par les utilisateurs (les configurations par défaut ne sont pas affectées). »
Jeff Williams, CTO et cofondateur de Contrast Security, est du même avis en ce qui concerne la gravité de la faille. Il pense que les tentatives d'exploiter ce défaut seraient exceptionnellement bruyantes et faciles à identifier et à bloquer. « Il semble que seuls quelques octets de cette information sont divulgués. Il serait donc extrêmement difficile d'obtenir quelque chose d'utile », a déclaré Williams. « Deuxièmement, seuls 400 serveurs sont affectés sur 1 million. Cela réduit considérablement les options d'attaque. [La vulnérabilité] a eu un excellent nom, OptionsBleed. Et c'est théoriquement intéressant. Mais il n'y a pas beaucoup de danger pour vous et pour moi. Mettez à niveau votre serveur et allez de l'avant », a-t-il ajouté.
En ce qui concerne les mises à jour pour appliquer le correctif, Ylavic estime encore que ça sera quelque chose de facile pour les utilisateurs ; ce qui devrait donc permettre de corriger rapidement les serveurs vulnérables. En effet, pour les utilisateurs de moyenne et grande taille, il existe généralement une architecture ou une procédure qui permet de faire la maintenance sans interruption, dit-il. Et pour les plus petits utilisateurs avec un seul serveur et aucun équilibrage de charge frontend, il faudra juste un petit moment d’interruption pour corriger le problème, ce qui est d'ailleurs prévu pour toute maintenance. Il indique par ailleurs que « le correctif consiste également à empêcher la mauvaise configuration, de sorte que certains utilisateurs devront adapter leur configuration (si jamais ils en avaient vraiment besoin). »
Il faut également préciser que le problème était déjà connu depuis 2014, mais ce n’est que maintenant qu’il est en train d’être corrigé par la fondation Apache.
Sources : Hanno Bock, Threatpost
Et vous ?
Qu’en pensez-vous ?
Optionsbleed a-t-il été surestimé par le chercheur qui a découvert le problème ?
Voir aussi :
Equifax pointe du doigt une faille dans Apache Struts qui aurait été utilisée pour accéder aux informations de 143 millions de ses clients américains
Apache Struts : une faille dans le framework permet l'exécution de code à distance, si la version utilisée est antérieure à 2.5.13
Yahoobleed : une faille 0-day a causé la fuite de données des utilisateurs, les ingénieurs de Yahoo ont retiré la bibliothèque ImageMagick