Le package NPM avec 3 millions de téléchargements hebdomadaires a eu un grave

Le package NPM populaire « pac-resolver » a corrigé une grave faille d’exécution de code à distance (RCE).

Le package pac-resolver reçoit plus de 3 millions des téléchargements hebdomadaires, étendant cette vulnérabilité aux applications Node.js reposant sur la dépendance open source. Pac-resolver se présente comme un module qui accepte les fichiers de configuration de proxy JavaScript et génère une fonction permettant à votre application de mapper certains domaines afin d’utiliser un proxy.

Mandataire ou non mandataire

Cette semaine, développeur Tim Perry a révélé une faille de haute gravité dans pac-resolver qui peut permettre aux acteurs malveillants sur le réseau local d’exécuter du code arbitraire dans votre processus Node.js chaque fois qu’il tente de faire une requête HTTP.

Tout en ajoutant le support proxy à son Boîte à outils HTTP, Perry a commencé à auditer le code pac-resolver et a rencontré le problème de sécurité. Suivi comme CVE-2021-23406, la vulnérabilité est liée à la façon dont les fichiers Proxy Auto-Config (PAC) sont traités par le module. Les fichiers PAC sont constitués de code JavaScript spécifiant une configuration de proxy, quelles requêtes réseau doivent passer par un proxy et lesquelles doivent sortir directement. Par exemple, dans un fichier PAC, les administrateurs réseau peuvent spécifier explicitement un proxy réseau via lequel tout le trafic doit être acheminé et afficher les domaines exemptés de l’exigence :

function FindProxyForURL(url, host) {
// Send all *.example requests directly with no proxy:
if (dnsDomainIs(host, '.example.com')) {
return 'DIRECT';
}

// Send every other request via this proxy:
return 'PROXY proxy.example.com:8080';
}

Dans l’exemple ci-dessus, les requêtes réseau à « example.com » contourneront le proxy, tandis que le reste du trafic doit passer par un serveur proxy.

Initialement introduit dans le cadre de Netscape Navigator 2.0 en 1996, le Norme PAC reste pertinent et largement utilisé aujourd’hui. Par exemple, Web Proxy Auto-Discovery Protocol (WAPD) utilise les services DNS et/ou DHCP pour localiser les fichiers PAC sur un réseau et importer la configuration du proxy dans une application. Cependant, à mesure que les configurations de proxy deviennent plus volumineuses, le code JavaScript dans un fichier PAC peut devenir de plus en plus complexe et est idéalement conçu pour s’exécuter dans un environnement virtualisé (VM).

Peu de lignes de JavaScript peuvent contourner la VM, conduire à RCE

Et c’est là que le problème commence.

Par exemple, un package NPM associé appelé Pac-Proxy-Agent, qui est créé par le même auteur et compte plus de 2 millions de téléchargements hebdomadaires, fournit une prise en charge des fichiers PAC aux applications Node.js. Pac-Proxy-Agent le fait en saisissant l’URL d’un fichier PAC, en récupérant le fichier, puis en agissant comme un agent HTTP Node.js gérant les requêtes sortantes pour votre application. Mais Pac-Proxy-Agent ne parvient pas à mettre en bac à sable les fichiers PAC correctement car il utilise le module vulnérable pac-resolver, qui s’appuie en outre sur « degenerator » pour construire la fonction PAC.

Degenerator est encore un autre paquet par le même auteur qui aide à transformer du code arbitraire en une fonction sandbox à l’aide du module « VM » de Node.js. Mais le module VM n’a jamais été conçu pour être utilisé comme mécanisme de sécurité, ce qui est explicitement énoncée dans la documentation Node.js. Par conséquent, la sortie de degenerator, lorsqu’elle est utilisée par une chaîne de packages tels que pac-resolver, Pac-Proxy-Agent et proxy-agent, pose un risque de sécurité.

Se référant à une clause de non-responsabilité dans la documentation de Node disant : « Le module vm n’est pas un mécanisme de sécurité. Ne l’utilisez pas pour exécuter du code non fiable », Perry a déclaré dans un article de blog, « C’est une erreur facile à faire – c’est un petit texte (franchement, il devrait être le titre sur cette page et à côté de chaque méthode) et MongoDB a fait le exactement la même chose aussi en 2019, avec des conséquences encore pires. »

Perry a expliqué en outre que « cela crée un gros problème. Bien que VM essaie de créer un environnement isolé dans un contexte séparé, il existe une longue liste de moyens simples d’accéder au contexte d’origine et de sortir complètement du bac à sable … permettant au code à l’intérieur le ‘bac à sable’ pour faire tout ce qu’il veut sur votre système. »

Avec cela, Perry a partagé un code d’exploit de preuve de concept démontrant comment un attaquant peut sortir de la VM :

« C’est tout, c’est tout ce qu’il faut pour sortir du bac à sable du module VM. Si vous pouvez faire en sorte qu’une cible vulnérable utilise ce fichier PAC comme configuration de proxy, alors vous pouvez exécuter du code arbitraire sur sa machine », a-t-il expliqué.

La vulnérabilité affecte sérieusement ceux qui utilisent des versions de pac-resolver antérieures à 5.0.0, même de manière transitive dans leur application Node.js, et :

• Utiliser explicitement les fichiers PAC pour la configuration du proxy ou
• Lisez et utilisez la configuration du proxy du système d’exploitation dans Node.js sur les systèmes avec WPAD activé ou
• Utiliser la configuration proxy (env vars, fichiers de configuration, points de terminaison de configuration distants, arguments de ligne de commande) à partir d’une source non fiable

Un attaquant distant peut, dans n’importe lequel de ces scénarios, configurer une URL PAC malveillante et exécuter du code arbitraire sur un ordinateur à chaque fois qu’une requête HTTP est effectuée à l’aide de la configuration du proxy.

Le correctif pour pac-resolver dans la version 5.0.0 consiste simplement à se cogner la version dégénérateur à 3.0.1. Le correctif de base est entré dans le dégénérateur lui-même et implémente un mécanisme de bac à sable via le module vm2 pour « empêcher l’escalade des privilèges du code non fiable ».

Perry a remercié Snyk d’avoir soutenu le développeur tout au long du processus coordonné de divulgation des vulnérabilités.

Les développeurs concernés doivent effectuer une mise à niveau vers pac-resolver version 5.0.0 ou supérieure pour corriger cette grave vulnérabilité dans leurs applications.