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.
