Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Serveurs Apache : une faille sérieuse, mais pas si dangereuse

Non ce n'est pas le nouveau Heartbleed
Logiciel 3 min
Serveurs Apache : une faille sérieuse, mais pas si dangereuse
Crédits : rkankaro/iStock

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. 

12 commentaires
Avatar de KP2 Abonné
Avatar de KP2KP2- 20/09/17 à 16:24:33

Mouais, effectivement, y'a pas de panique...

Avatar de revker Abonné
Avatar de revkerrevker- 20/09/17 à 17:26:59

Pas une menace très sérieuse. Etant donné que des patchs sont déjà disponibles, pas de quoi s"inquiéter :)

Avatar de Burn2 Abonné
Avatar de Burn2Burn2- 20/09/17 à 17:32:19

Patch déjà téléchargé chez debian. :)

Avatar de Manozco Abonné
Avatar de ManozcoManozco- 20/09/17 à 17:33:06

Va dire ca a Equifax :)
Le patch pour leur probleme de secu etait dispo en mars :)

Avatar de grsbdl INpactien
Avatar de grsbdlgrsbdl- 20/09/17 à 18:09:25

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 ? :langue:

Édité par grsbdl le 20/09/2017 à 18:11
Avatar de _Quentin_ Abonné
Avatar de _Quentin__Quentin_- 20/09/17 à 18:20:55

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 :chinois:

Avatar de 127.0.0.1 INpactien
Avatar de 127.0.0.1127.0.0.1- 20/09/17 à 18:28:05
  1. Tous les bugs ne sont pas des vulnérabilités.

    1. Toutes les vulnérabilités ne sont pas exploitables depuis chez soi.
    2. Tous les logiciels avec une vulnérabilité exploitable depuis chez soi ne sont pas déployés sur 75 millions de sites web.

    La vulnérabilité a beau être peu dangereuse, elle reste digne d'intérêt.

Avatar de grsbdl INpactien
Avatar de grsbdlgrsbdl- 20/09/17 à 18:35:56

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.

Édité par grsbdl le 20/09/2017 à 18:39
Avatar de Vincent_H Équipe
Avatar de Vincent_HVincent_H- 21/09/17 à 05:57:42

Désamorcer le ton gravissime adopté par certains médias, ça nous arrive régulièrement de le faire ;)

Avatar de grsbdl INpactien
Avatar de grsbdlgrsbdl- 21/09/17 à 10:41:45

Bien vu ;)

Il n'est plus possible de commenter cette actualité.
Page 1 / 2