Failles NGINX : 5 vulnérabilités corrigées, dont un risque de RCE
Les failles NGINX corrigées le 14 octobre : cinq bugs, dont un risque d'exécution de code et un contournement TLS possible.
Les failles NGINX font l’actualité. En effet, le 14 octobre, les mainteneurs du serveur web ont publié les versions 1.30.6 et 1.31.7. Ces mises à jour corrigent cinq vulnérabilités. Parmi elles, une est présente dans toutes les versions depuis mai 2005. Autrement dit, elle a survécu à vingt ans de développement.
F5, l’entreprise qui édite NGINX, détaille plusieurs de ces défauts. Par ailleurs, certains peuvent faire planter un processus. D’autres pourraient, dans le pire des cas, permettre l’exécution de code. Les administrateurs doivent donc évaluer rapidement leur exposition.
Failles NGINX : ce que contiennent les versions 1.30.6 et 1.31.7
Ces deux versions appartiennent à deux branches distinctes. La 1.30.6 correspond à la branche stable. En revanche, la 1.31.7 correspond à la branche principale, qui reçoit les nouveautés en premier. Les deux embarquent également les mêmes correctifs de sécurité.
Au total, cinq vulnérabilités sont traitées. D’abord, trois sont des erreurs de gestion de la mémoire. Ensuite, une quatrième touche le protocole TLS. En revanche, les informations disponibles ne détaillent pas la cinquième. Il faudra donc consulter les avis de sécurité officiels pour en connaître la nature exacte.
Un point mérite l’attention. Au moins une de ces failles remonte à mai 2005. Elle affecte ainsi toutes les versions publiées depuis cette date. Par conséquent, l’ancienneté d’une installation ne la protège pas. Au contraire, les très vieux déploiements restent les plus exposés.
Trois bugs mémoire et un risque d’exécution de code
Les trois premières failles sont des bugs de corruption ou de mauvaise gestion de la mémoire. Ainsi, selon F5, elles peuvent provoquer l’arrêt d’un processus de travail, appelé worker. Elles pourraient également, dans certains cas, ouvrir la voie à l’exécution de code à distance.
Le conditionnel est important ici. En effet, F5 précise que chaque bug exige une configuration particulière pour être exploité. Un serveur NGINX installé avec les réglages par défaut n’est donc pas forcément vulnérable. En revanche, un serveur utilisant certaines directives ou certains modules peut l’être.
Pourquoi un plantage de worker reste sérieux
Un worker qui s’arrête n’est pas anodin. En effet, NGINX en relance généralement un nouveau. Cependant, un attaquant peut répéter l’opération en boucle. Il provoque alors des coupures de service et dégrade la disponibilité du site.
De plus, un bug mémoire est souvent le premier maillon d’une chaîne d’attaque. Un simple plantage peut révéler une faille plus grave. C’est pourquoi les éditeurs parlent d’exécution de code « possible », même quand aucune exploitation n’est confirmée.
Une exploitation soumise à la configuration
La dépendance à la configuration limite la surface d’attaque. Toutefois, elle complique aussi l’évaluation du risque. Chaque équipe doit donc relire ses fichiers de configuration. Elle doit repérer les directives citées dans les avis de F5. Ensuite, elle peut décider de l’urgence de la mise à jour.
Un défaut TLS qui menace la vérification des certificats clients
La quatrième vulnérabilité concerne TLS. Elle permettrait à un attaquant de forger une session TLS. Selon le titre de la publication d’origine, cela pourrait conduire à ignorer les contrôles de certificat client. Cependant, les détails complets n’ont pas été fournis dans les éléments dont nous disposons.
Ce scénario inquiète particulièrement certaines organisations. En effet, beaucoup d’entreprises utilisent l’authentification par certificat client, ou TLS mutuel. Elles l’emploient par exemple pour protéger des API internes, des interfaces d’administration ou des échanges entre services. Si ce contrôle est contourné, une barrière essentielle disparaît.
Toutefois, il faut rester prudent. Rien n’indique, à ce stade, que cette faille soit exploitée dans la nature. Néanmoins, les équipes qui s’appuient sur le TLS mutuel doivent la traiter en priorité.
Que faire face aux failles NGINX ?
La réponse est simple : mettre à jour. En effet, les correctifs sont disponibles dans les deux versions publiées le 14 octobre. Voici la marche à suivre.
- D’abord, inventorier tous les serveurs NGINX, y compris ceux qui servent de reverse proxy, de répartiteur de charge ou de passerelle API.
- Ensuite, identifier la version en service avec la commande
nginx -v. - Passer à la version 1.30.6 pour la branche stable, ou à la 1.31.7 pour la branche principale.
- Par ailleurs, relire la configuration pour repérer les réglages décrits dans les avis de F5.
- Enfin, redémarrer ou recharger le service afin que le correctif soit réellement actif.
Par ailleurs, pensez aux produits qui embarquent NGINX. Certaines images de conteneurs, distributions Linux et appliances reprennent le logiciel. Leur mise à jour dépend alors de leur éditeur. Il faut donc vérifier leurs bulletins de sécurité.
Ce qu’il faut retenir
- NGINX 1.30.6 et 1.31.7 corrigent cinq vulnérabilités, publiées le 14 octobre.
- Une faille est présente dans toutes les versions depuis mai 2005.
- Trois bugs mémoire peuvent faire planter un worker ou, éventuellement, permettre l’exécution de code.
- Toutefois, chacun de ces bugs requiert une configuration spécifique pour être exploité.
- Par ailleurs, un défaut TLS pourrait affaiblir la vérification des certificats clients.
- Enfin, la mise à jour reste la mesure la plus efficace, complétée par une revue de configuration.
Source : NGINX Fixes 5 Flaws, Including Possible RCE and a TLS Bug That May Skip Client-Cert Checks