Le changement, attendu en juillet, bloquera probablement l’un des vecteurs d’attaque les plus courants ; les développeurs se demandent pourquoi GitHub a mis autant de temps et pourquoi d’autres référentiels ont agi beaucoup plus tôt.
La possibilité pour les attaquants d’exploiter l’exécution automatique du script d’installation dans npm prendra enfin fin lorsque les modifications attendues arriveront de GitHub en juillet. Les codeurs pourront toujours activer la fonction, mais le paramètre par défaut la bloquera.
Dans la V12, les paramètres par défaut changent, a déclaré GitHub dans son journal des modifications, notant : « cela transforme un comportement d’installation npm qui s’exécute automatiquement aujourd’hui en un comportement dans lequel vous optez explicitement ».
Plus précisément, le message indiquait : « allowScripts est désactivé par défaut : npm install n’exécutera plus les scripts de préinstallation, d’installation ou de post-installation à partir des dépendances à moins qu’ils ne soient explicitement autorisés dans votre projet. Cela inclut les versions natives de node-gyp ; un paquet avec un fichier contraignant.gyp et aucun script d’installation explicite est toujours bloqué, car npm exécute une reconstruction implicite de node-gyp pour cela. Les scripts de préparation à partir des dépendances git, file et link sont bloqués de la même manière. «
Les analystes, les consultants et les utilisateurs ont généralement applaudi ce changement, mais ont déclaré qu’il ne ferait que réduire l’exposition aux attaques de la chaîne d’approvisionnement au lieu de l’éliminer.
Les attaques risquent de se déplacer ailleurs
Sonu Kapoor, responsable de la CLI CVE Lite dans le projet d’incubateur OWASP, a déclaré que ce changement est susceptible de forcer les attaques de la chaîne d’approvisionnement qui exploitaient l’exécution automatique à se déplacer ailleurs.
« Cela n’élimine pas le risque de chaîne d’approvisionnement npm, cela supprime un chemin d’exécution automatique majeur », a déclaré Kapoor. « Les attaquants peuvent toujours emprunter d’autres chemins : code de package malveillant qui s’exécute au moment de l’exécution de l’application, comptes du responsable compromis, confusion des dépendances, fautes de frappe, flux de travail GitHub Actions empoisonnés, dépendances transitives malveillantes ou jetons de publication volés. Cela ferme une porte très dangereuse, mais cela ne sécurise pas toute la maison. «
Pourtant, des attaques exploitant ce paramètre ont été régulièrement utilisées dans les attaques de la chaîne d’approvisionnement.
Cependant, Alan Parkinson, directeur de la société de dispositifs médicaux sécurisés Threat Detective, a déclaré que des attaquants plus sophistiqués ont déjà dépassé ce trou.
« Le vecteur d’attaque des scripts d’installation est connu depuis des années », a déclaré Parkinson. « La plupart des équipes de sécurité l’ont identifié comme présentant un risque faible et sont passées à des menaces à risque plus élevé. Ce qui a rehaussé sa visibilité n’est pas l’évolution de l’exploitabilité technique, mais plutôt une série de victimes de haut niveau et certains acteurs malveillants recherchant ouvertement la notoriété. »
Il a ajouté : « Les scripts de pré et post-installation n’ont jamais été un vecteur d’attaque intelligent. L’exécution de code à partir d’un hook d’installation est grossière et bruyante, c’est pourquoi cela a causé des dommages aussi visibles. Les acteurs les plus compétents se tournent déjà vers d’autres méthodes, donc la v12 ferme principalement la porte aux acteurs de menace moins sophistiqués. «
Bien que GitHub ait refusé une interview, Zach Steindler, ingénieur principal de GitHub, a répondu aux questions par e-mail. Il a déclaré que le volume et le rythme des attaques contre la chaîne d’approvisionnement ont forcé la modification des paramètres par défaut.
« Nous avons vu des attaquants cibler ces capacités pour propager rapidement des attaques d’un paquet compromis à plusieurs. Des années de recherche sur la sécurité et l’utilisabilité ont montré qu’il ne suffit pas de rendre disponible une fonctionnalité sécurisée ; le chemin sécurisé doit être le chemin par défaut pour qu’il soit largement adopté », a déclaré Steindler.
Il a ajouté : « Nous pensons que ces changements constituent un excellent moyen de fournir des paramètres sécurisés par défaut à fort impact tout en offrant à certains utilisateurs la possibilité de recourir aux fonctionnalités dont ils pourraient avoir besoin dans certaines circonstances. »
Modification en retard
Sanchit Vir Gogia, analyste en chef chez Greyhound Research, a déclaré que GitHub était le dernier des référentiels à modifier les paramètres par défaut. « Les rivaux ont agi en premier : Yarn, pnpm et Bun bloquent tous les scripts d’installation tiers par défaut, à leur manière », a déclaré Gogia. « Le Npm n’invente pas une nouvelle doctrine. Il en adopte finalement une. »
Steindler n’a pas contesté le commentaire de Gogia.
« Ce n’est pas facile d’être l’administrateur du plus grand dépôt de paquets au monde. Le consensus de la communauté sur les capacités de sécurité qui devraient être standard et sur le moment où il est acceptable d’apporter des modifications radicales évolue au fil du temps. D’après nos conversations continues avec la communauté, il était clair qu’il était temps de procéder à ce changement », a déclaré Steindler.
« Les récentes attaques sont alarmantes », a-t-il noté, « mais la gestion de ces référentiels de paquets est un effort de plusieurs décennies, et pas seulement un instant. À mesure que les attaques évoluent, nos capacités de sécurité défensive évoluent également. Nous sommes là pour le long terme. »
Gogia a déclaré que le changement, bien que attendu depuis longtemps, est une bonne chose.
« Npm supprime l’une des cachettes les plus confortables pour les risques de la chaîne d’approvisionnement logicielle : le code qui s’exécute au moment où un développeur tape l’installation », a déclaré Gogia. « Avec npm v12, l’exécution devient quelque chose qui doit être approuvé, enregistré dans le projet et validé pour examen. Il ne s’agit pas d’un ajustement de conception. C’est un changement de philosophie de contrôle. »
Les mauvais défauts deviennent une infrastructure
Gogia avait sa propre vision des raisons pour lesquelles GitHub avait attendu si longtemps.
« Npm a attendu parce que son risque de défaut a acquis une certaine popularité. Dès 2016, la propre position de npm était que la commodité des scripts d’installation l’emportait sur le risque de ver, avec un indicateur de désinscription pour les plus prudents. Le compromis était une décision documentée sur le produit, pas un oubli », a-t-il déclaré.
« Le problème des défauts de paiement, c’est qu’ils se transforment en infrastructures », a-t-il ajouté. « Les versions de modules natifs, les installateurs de navigateurs tels que Playwright et Cypress, les flux de téléchargement Electron et les hooks Husky se sont tous développés autour de l’exécution automatique. La désactiver est devenue moins un ajustement technique qu’une réforme constitutionnelle. «
La responsabilité a changé de mains
Toutefois, la véritable pression en faveur du changement est venue des régulateurs.
« La réponse la plus profonde est que la responsabilité a changé de mains. Une fois que des réglementations telles que la loi européenne sur la cyber-résilience et les règles de divulgation des titres ont placé la défaillance de la chaîne d’approvisionnement dans les bilans des entreprises, un défaut de paiement dangereux et documenté est devenu indéfendable », a déclaré Gogia.
Kapoor a reconnu que les procédures utilisées de longue date ont permis à cette faille de sécurité de survivre plus longtemps qu’elle n’aurait dû.
« La raison pour laquelle cela n’a probablement pas été fait il y a longtemps est la compatibilité », a-t-il déclaré. « Les scripts d’installation ne sont pas seulement utilisés par les attaquants. De nombreux packages légitimes les utilisent pour compiler des modules natifs, télécharger des binaires spécifiques à la plate-forme, générer des fichiers ou effectuer des étapes de configuration. La modification de la valeur par défaut rompt les hypothèses qui existent dans l’écosystème npm depuis des années. C’est pourquoi ces changements de sécurité arrivent souvent lentement. La valeur par défaut la plus sûre est évidente du point de vue de la sécurité, mais douloureuse du point de vue de la compatibilité de l’écosystème. «
En outre, a-t-il noté, « le point le plus important est que les gestionnaires de packages passent d’une confiance implicite à une confiance explicite. C’est la bonne direction. Les développeurs devraient avoir à approuver quelles dépendances sont autorisées à exécuter du code lors de l’installation. Mais l’approbation ne peut pas devenir une case à cocher aveugle. Les équipes ont besoin de visibilité sur quel package souhaite exécuter un script, s’il est direct ou transitif, pourquoi il est là et s’il appartient au projet. »
Kapoor a ajouté que ce changement est important car l’exécution au moment de l’installation se produit souvent dans des environnements privilégiés avec accès aux jetons, secrets, registres internes, artefacts de build ou chemins de déploiement. « Même si le script ne compromet pas directement la production, il peut être capable de voler suffisamment de contexte pour soutenir la prochaine étape d’une attaque », a-t-il déclaré.
Valeur dans la douleur
Le consultant en cybersécurité Brian Levine, directeur exécutif de FormerGov, a convenu que la fermeture de cette faille de sécurité est une très bonne chose.
« Il semble que pratiquement toutes les attaques majeures de la chaîne d’approvisionnement de la dernière décennie ont eu le même péché originel : un code qui s’exécutait automatiquement parce que l’écosystème le permettait. Npm ferme finalement cette porte par défaut, mais c’est vraiment important. Il s’agit du gestionnaire de paquets pour des centaines de milliards de téléchargements par mois », a déclaré Levine.
« Lorsque npm modifie ses valeurs par défaut, cela modifie la posture de sécurité de pratiquement tous les environnements de développement d’entreprise de la planète. Il s’agit peut-être du dernier grand référentiel de code à permettre encore ce type d’exécution automatisée. «
Levine a ajouté que ce changement pourrait non seulement mettre fin à une faille de sécurité, mais que le nouveau processus pourrait améliorer considérablement la sécurité.
« Il y a en fait quelque chose de précieux enfoui dans cette difficulté de migration. Demander aux développeurs d’approuver explicitement quels packages peuvent exécuter du code et de soumettre cette liste au contrôle de code source est une forme de gouvernance de la chaîne d’approvisionnement logicielle que de nombreuses organisations n’ont jamais eue », a déclaré Levine. « Cela crée un enregistrement vérifiable qui est significatif, en particulier pour les industries réglementées. »
