Une importante faille de sécurité a été découverte dans le serveur web Apache. Exploitée, elle peut mener à la divulgation d’informations en visant certaines zones de la mémoire. Elle devient en outre plus dangereuse sur des serveurs utilisés par plusieurs clients.
La faille a été trouvée par le journaliste Hanno Böck, qui a publié lundi un billet de blog expliquant les détails de la vulnérabilité, estampillée CVE-2017-9798. Il y indique qu’habituellement, les clients (notamment les navigateurs) effectuent des requêtes vers les serveurs en passant par des requêtes GET et POST, qui permettent d’en récupérer le contenu. Il en existe cependant d’autres sur Apache, dont OPTIONS, une méthode qui permet justement de connaître les requêtes supportées par le serveur web, ici Apache.
La réponse du serveur se présente avec un en-tête « Allow », puis par une liste des requêtes séparées par des points-virgules. Comme le journaliste l’explique cependant, certains sites renvoient des réponses déformées, présentant a priori des données corrompues. Les points-virgules peuvent ainsi être remplacés par une ou plusieurs virgules, et les noms de requêtes par d’autres mots, voire des liens complets. Des séquences qu’un serveur ne renvoie normalement pas.
Des conditions d'exploitation très précises
En se penchant de plus près sur ces résultats, Hanno Böck a découvert qu’il s’agissait en fait de fuites de données. Elles étaient provoquées par l’envoi de requêtes spécialement conçues pour exploiter un bug dans le serveur Apache, de type « use after free ». Pour rappel, ce genre d’erreur permet d’entrainer un plantage dans un composant logiciel en faisant référence à des données qui ne sont plus disponibles en mémoire.
D’après ses propres recherches, il faut que le serveur réunisse certaines conditions. Il doit d’abord être très occupé. Ensuite, les soucis sont liés à la présence des fichiers .htaccess dans les dossiers du serveur. Ce point a été confirmé par Jacob Champion, développeur Apache chargé de l’enquête sur le problème. Il rappelle que ces fichiers définissent les requêtes auxquelles le serveur peut répondre pour les dossiers dans lesquels ils se trouvent.
Et c’est ici que le bug se produit, de manière assez spécifique. Il faut en effet qu’un administrateur ait défini dans le fichier .htaccess une directive de configuration Limit faisant référence à des méthodes HTTP n’ayant pas été globalement enregistrées à l’échelle du serveur. C’est là que les requêtes spécialement conçues interviennent, provoquant l’erreur de type « use after free » et donc la fuite de données.
Un risque relativement faible
Selon Hanno Böck et Jacob Champion, le risque global reste finalement assez faible. Sur le million de sites scannés (les sites les plus visités dans le Top Alexa) par le journaliste, seuls 466 serveurs renvoyaient des en-têtes corrompus. Ils comparent tous deux le type de bug à Heartbleed, sans en avoir la gravité. Les conditions à réunir sont beaucoup plus strictes et les tranches de mémoire renvoyées sont plus petites.
Le risque est cependant plus important pour les configurations serveurs où plusieurs clients se partagent la même machine. Un cas qui est loin d’être particulier, la mutualisation du matériel intervenant dans de nombreux scénarios. Puisque la mémoire est partagée, il devient possible d’affecter plusieurs clients d’un coup si le serveur est suffisamment occupé pour permettre l’émission des en-têtes corrompus.
Des patchs manuels déjà disponibles
En d’autres termes, le bug est considéré comme sérieux, mais pas réellement grave. Des patchs sont d’ailleurs déjà prêts pour les versions 2.2.X et 2.4.X d’Apache (attention, l'application est manuelle). La plupart des distributions Linux – qui intègrent souvent le serveur web – ont normalement déjà intégré et commencé à distribuer la mise à jour. Notez que la fondation Apache ne propose pas encore de nouvelles moutures contenant le correctif.
Selon Yann Ylavic, du comité de gestion du serveur Apache, aucune utilisation malveillante de ce bug n’a pour l’instant été découverte. Il ajoute par ailleurs que même sur les configurations partagées, il est possible d’atténuer les risques pour les systèmes qui n’ont pas été mis à jour. Dans la configuration principale, il suffirait ainsi de définir des directives, qui ne pourront alors pas être modifiées par les utilisateurs.
Commentaires (12)
Mouais, effectivement, y’a pas de panique…
Pas une menace très sérieuse. Etant donné que des patchs sont déjà disponibles, pas de quoi s”inquiéter :)
Patch déjà téléchargé chez debian. :)
Va dire ca a Equifax :)
Le patch pour leur probleme de secu etait dispo en mars :)
Pour le coup j’ai du mal à voir l’intérêt de cette news sur NI.
" />
Lorsqu’un logiciel grand public a de gros soucis (au hasard, CCleaner, dont vous parliez hier), votre actu est pertinente car beaucoup de lecteurs sont concernés et doivent (ré)agir.
Là, on parle d’Apache Http Server, dont le bugtracker regorge de bugs, failles, todos (comme plein d’autres logiciels). Alors que l’on parle ici de failles critiques et affectant rapidement les internautes, je comprends (hearthbleed…), mais là quel est l’intérêt ? Les admins sys sont déjà au courant. Pourquoi ne pas carrément dépiler le backlog de Spring Framework, Nginx, les navigateurs web, Filezilla, MySQL, etc ?
C’est un choix de la rédaction de traiter certains sujets, ici un bug comme “Heartbleed, sans en avoir la gravité”, ça parle à beaucoup de monde (dans le domaine IT).
" />
Perso je trouve ça intéressant même si ça me touche pas directement
La vulnérabilité a beau être peu dangereuse, elle reste digne d’intérêt.
Je sais très bien qu’Apache fait tourner le gros de l’intertube :p Ce dont je m’étonne, c’est que l’on parle sur NI d’un des soucis de ce serveur alors que ce n’est pas le seul (d’où ma référence au backlog plein à craquer), et l’article va même jusqu’à dire qu’en fait non, c’est pas si grave.
En suivant la logique qui a motivé cette news, on pourrait parler des vieilles failles de sécurité non résolues de Spring Framework, lequel est utilisé sur énormément de backends (et pas que, par exemple, l’utilitaire desktop des SSD Crucial est une webapp locale basée sur un vieux Spring ^_^, j’ai fait un bond de 3m en constatant ça), dont des sites institutionnels.
Désamorcer le ton gravissime adopté par certains médias, ça nous arrive régulièrement de le faire ;)
Bien vu ;)
Heu et si la rédaction a envie de faire un sujet dessus ? La liberté c’est un truc bizarre hein ?
En plus je discerne d’après tes propos hérétiques que tu ne fais pas tourner Apache sur une de tes machines ou pire si tu n’en a qu’une seule.
Bon, il va falloir la faire Médiévale. Sortez moi le mal-confort, la table d’écartèlement. 127.0.0.1 ranges ce bazooka ça ne fait pas assez mal sur le long. Sors plutôt les masses à pointes et le papier de verre type N°2.
Cette faille est compliquée à exploiter tout de même, je ne sais pas si ça vaut en effet la pertinence d’une news, maintenant c’est la liberté de NXI d’en faire une et des lecteurs de la lire ou pas.