Une faille Node.js dans le décodeur Brotli peut mener à l'exécution de code à distance sur les trois branches prises en charge.

Le projet Node.js a publié des correctifs de sécurité le 21 octobre. Cette mise à jour corrige une faille Node.js particulièrement sérieuse, située dans le code de décompression Brotli. Elle touche les trois branches encore prises en charge : 22.x, 24.x et 26.x. Au total, dix vulnérabilités sont corrigées dans cette série de versions.

Une faille Node.js critique dans le décodeur Brotli

Parmi les dix failles, une se distingue nettement. Elle réside dans le composant Brotli, que Node.js embarque directement dans ses sources. Selon le projet, ce défaut peut conduire à une exécution de code à distance. Autrement dit, un attaquant pourrait faire tourner le code de son choix sur le système vulnérable.

Il s’agit du scénario le plus redoutable pour un serveur. En effet, l’attaquant n’a pas besoin d’un accès préalable à la machine. Il lui suffit de lui faire traiter des données piégées. Ensuite, il peut espérer prendre le contrôle du processus Node.js, avec les droits de ce dernier.

Chaque branche supportée dispose d’une version corrigée unique. Les informations dont nous disposons ne détaillent toutefois ni les numéros précis ni l’identifiant CVE associé. Par conséquent, il faut se référer aux notes de version officielles du projet pour connaître la cible exacte de la mise à jour.

Pourquoi la décompression est une surface d’attaque sensible

Brotli est un algorithme de compression de données très répandu. Il sert notamment à réduire la taille des contenus échangés sur le web. Node.js l’intègre pour permettre de compresser et de décompresser des flux. De nombreuses applications s’appuient sur cette fonction, souvent sans que les développeurs y pensent.

Or, un décodeur lit des données qui viennent de l’extérieur. C’est pourquoi il constitue une cible de choix. Une erreur de traitement dans ce type de code peut avoir de lourdes conséquences. Les bibliothèques de décompression ont d’ailleurs déjà été à l’origine de nombreuses vulnérabilités dans d’autres logiciels.

De plus, le composant est embarqué dans Node.js. Les équipes ne peuvent donc pas le corriger séparément. Elles doivent mettre à jour l’environnement d’exécution lui-même. Cette contrainte explique pourquoi la diffusion d’une nouvelle version est la seule réponse efficace.

Quels environnements sont concernés ?

Le projet annonce que les trois lignes supportées sont touchées. Tout serveur qui exécute l’une de ces branches doit donc être considéré comme potentiellement exposé. Cela concerne les API, les services web et les outils de build. Cela concerne aussi les applications fonctionnant dans des conteneurs.

Le risque dépend toutefois de l’usage réel. Une application qui décompresse des données Brotli venant d’utilisateurs ou de services tiers présente une exposition plus forte. En revanche, un service qui n’utilise jamais cette fonction sera probablement moins exposé. Néanmoins, il reste prudent de ne pas compter sur cette hypothèse. Les dépendances peuvent appeler Brotli à votre insu.

Comment réagir face à cette faille Node.js

La priorité est simple : mettre à jour. Il faut d’abord identifier les versions de Node.js en production. Ensuite, il convient de les comparer aux versions corrigées publiées le 21 octobre. Enfin, le déploiement doit suivre un calendrier court, en commençant par les services accessibles depuis Internet.

Plusieurs points méritent une attention particulière :

• Les images de conteneurs, qui embarquent souvent leur propre version de Node.js et doivent être reconstruites.
• Les serveurs de build et d’intégration continue, qui exécutent fréquemment du code Node.js avec des privilèges élevés.
• Les environnements de développement, souvent oubliés dans les campagnes de mise à jour.
• Les applications packagées avec leur propre runtime, comme certains outils de bureau.

Par ailleurs, les neuf autres vulnérabilités corrigées ne doivent pas être négligées. Elles sont probablement moins graves que la faille Brotli. Cependant, elles justifient à elles seules l’application rapide de la mise à jour. Une seule opération permet de tout traiter.

Réduire l’exposition en attendant le correctif

Si le déploiement ne peut pas être immédiat, quelques mesures limitent le risque. Par exemple, on peut restreindre les flux entrants non fiables. On peut aussi faire tourner le processus avec le minimum de droits. De plus, une segmentation réseau réduit l’impact d’une éventuelle compromission. Ces mesures ne remplacent pas le correctif, mais elles gagnent du temps.

La surveillance compte également. Des plantages inhabituels du processus Node.js, des erreurs de décompression ou des processus enfants inattendus doivent alerter. Les équipes de sécurité peuvent donc ajuster leurs règles de détection pendant la phase de transition.

Ce qu’il faut retenir

• Node.js a publié le 21 octobre des mises à jour pour les branches 22.x, 24.x et 26.x.
• Dix vulnérabilités sont corrigées, dont une faille grave dans le code Brotli embarqué.
• Selon le projet, cette faille peut permettre l’exécution de code à distance.
• Chaque branche supportée dispose d’une version corrigée : consultez les notes de version officielles pour les numéros exacts.
• Mettez à jour en priorité les services exposés à Internet, les conteneurs et les serveurs de build.

Source : Node.js Brotli Decoder Bug Could Allow Remote Code Execution in All Supported Versions