GitHub verrouille l'exécution des scripts d'installation pour npm

L'exploitation de l'exécution automatique de scripts d'installation dans des registres npm sur Github sera bientôt de l’histoire ancienne avec la v12 de npm install. Le site de partage de code envisage en effet des modifications qui entreront en vigueur en juillet pour résoudre ce grave souci de sécurité. Les développeurs pourront toujours activer la fonction d’exécution automatique de scripts npm, mais elle sera bloquée par défaut. Les paramètres  vont changer a indiqué GitHub dans son journal des modifications, précisant que « cela transforme le comportement actuel de npm install, qui s'exécute automatiquement, en un comportement auquel il faut explicitement consentir. »

Plus précisément, le message indiquait que la valeur par défaut de “allowScripts” est désactivée : “npm instal” n'exécutera plus les scripts “preinstall”, “install” ou “postinstall” des dépendances, à moins qu'ils ne soient explicitement autorisés dans votre projet. Cela inclut les builds natifs node-gyp ; un paquet contenant un fichier “binding.gyp” mais aucun script d'installation explicite sera tout de même bloqué, car npm exécute implicitement une reconstruction node-gyp pour celui-ci. Les scripts de préparation provenant de git, des fichiers et des dépendances de liens sont bloqués de la même manière. Les analystes, consultants et utilisateurs ont salué 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.

Ces attaques risquent de se déplacer ailleurs

Sonu Kapoor, responsable de la maintenance de CVE Lite CLI au sein du projet OWASP Incubator, a déclaré que cette évolution allait probablement contraindre les attaques SCM (supply chain) qui exploitaient l'exécution automatique à se tourner vers d'autres moyens. « Cela n'élimine pas le risque lié à la chaîne d'approvisionnement npm, mais supprime une voie majeure d'exécution automatique », a déclaré M. Kapoor. « Les attaquants peuvent toujours se tourner vers d’autres voies : du code de paquet malveillant s’exécutant au moment de l’exécution de l’application, des comptes de responsables compromis, la confusion des dépendances, le typosquatting, des workflows GitHub Actions empoisonnés, des dépendances transitives malveillantes ou des jetons de publication volés. Cela ferme une porte très dangereuse, mais cela ne sécurise pas toute la maison. » Néanmoins, les attaques exploitant ce paramètre ont été régulièrement utilisées dans le cadre d’attaques de la chaîne d’approvisionnement.

Cependant, Alan Parkinson, directeur de la société Threat Detective spécialisée dans la sécurité des dispositifs médicaux, a déclaré que les pirates les plus sophistiqués avaient déjà dépassé ce stade. « Le vecteur d’attaque par script d’installation est connu depuis des années », a-t-il déclaré. « La plupart des équipes de sécurité l’ont classé comme présentant un faible risque et se sont tournées vers des menaces plus graves. Ce qui a attiré l’attention, ce n’est pas un changement dans l’exploitabilité technique, mais une série de victimes très médiatisées et certains acteurs malveillants cherchant ouvertement à se faire connaître. » Il a ajouté : « Les scripts pré et post-installation n’ont jamais constitué un vecteur d’attaque particulièrement astucieux. L’exécution de code à partir d’un hook d’installation est grossière et bruyante, ce qui explique pourquoi elle a causé des dégâts aussi visibles. Les acteurs les plus compétents se tournent déjà vers d’autres méthodes, de sorte que la v12 de npm install ferme principalement la porte aux acteurs malveillants moins sophistiqués. »

GitHub contraint de réagir 

Bien que GitHub ait décliné notre demande d’interview, Zach Steindler, ingénieur principal chez GitHub, a répondu à nos questions par e-mail. Il a expliqué que l’ampleur et la fréquence des attaques visant la chaîne d’approvisionnement avaient contraint l’entreprise à modifier les paramètres par défaut. « Nous avons constaté que les pirates ciblaient ces fonctionnalités pour propager rapidement leurs attaques d’un paquet compromis à plusieurs autres. Des années de recherche en matière de sécurité et d’ergonomie ont montré qu’il ne suffit pas de mettre à disposition des fonctionnalités sécurisées ; le chemin sécurisé doit être le paramètre par défaut pour qu’il soit largement adopté », a déclaré M. Steindler. Il a ajouté : « Nous pensons que ces changements constituent un excellent moyen de fournir des paramètres par défaut sécurisés à fort impact, tout en offrant à certains utilisateurs la possibilité de se rabattre sur des fonctionnalités dont ils pourraient avoir besoin dans certaines circonstances. »

Sanchit Vir Gogia, analyste en chef chez Greyhound Research, a déclaré que GitHub était le dernier des référentiels à adopter ce changement de paramètre par défaut. « Les concurrents ont pris les devants : Yarn, pnpm et Bun bloquent tous par défaut les scripts d’installation tiers, chacun à sa manière », a déclaré M. Gogia. « Npm n’invente pas une nouvelle doctrine. Il en adopte enfin une. » M. Steindler n’a pas contesté le commentaire de M. Gogia. « Il n’est pas facile d’être les gardiens du plus grand référentiel de paquets au monde. Le consensus de la communauté sur les capacités de sécurité qui devraient être la norme, et sur le moment où il est acceptable d’apporter des changements radicaux, évolue avec le temps. D’après nos échanges continus avec la communauté, il était clair qu’il était temps d’opérer ce changement », a déclaré M. Steindler. « Les récentes attaques sont alarmantes », a-t-il noté, « mais la gestion de ces référentiels de paquets est un effort qui s'étend sur plusieurs décennies, et non un simple moment dans le temps. À mesure que les attaques évoluent, nos capacités de sécurité défensives évolueront elles aussi. Nous sommes engagés dans cette démarche sur le long terme. »

Un changement attendu au tournant

M. Gogia a déclaré que ce changement, bien qu'il se fasse attendre depuis longtemps, est une bonne chose. « Npm élimine l'une des cachettes les plus pratiques pour les risques liés à la chaîne d'approvisionnement logicielle : le code qui s'exécute dès qu'un développeur tape « install » », a déclaré M. Gogia. « Avec npm v12, l'exécution devient une opération qui doit être approuvée, consignée dans le projet et validée pour être examinée. Il ne s'agit pas d'un simple ajustement de conception. C'est un changement de philosophie en matière de contrôle. » L'analyste a sa propre explication quant à la raison pour laquelle GitHub a tant tardé. « Npm a attendu parce que son paramètre par défaut risqué avait fini par trouver son public. Dès 2016, la position officielle de npm était que la commodité des scripts d’installation l’emportait sur le risque de ver, avec un indicateur permettant aux plus prudents de désactiver cette fonctionnalité. Ce compromis était un choix produit documenté, et non une négligence », a-t-il déclaré. « Le problème avec les paramètres par défaut inadaptés, c’est qu’ils finissent par devenir partie intégrante de l’infrastructure », a-t-il ajouté. « Les builds de modules natifs, les installateurs de navigateur tels que Playwright et Cypress, les flux de téléchargement d’Electron et les hooks Husky se sont tous développés autour de l’exécution automatique. Désactiver cette fonctionnalité relevait moins d’un ajustement technique que d’une réforme structurelle. »

La véritable pression en faveur de ce changement est toutefois venue des autorités de régulation. « La réponse plus profonde réside dans le fait 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 informations financières ont fait peser la responsabilité des défaillances de la chaîne d’approvisionnement sur les bilans des entreprises, il est devenu indéfendable de laisser subsister un défaut de sécurité avéré », a déclaré M. Gogia. M. Kapoor a convenu que les procédures utilisées depuis longtemps avaient permis à cette faille de sécurité de perdurer 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 uniquement utilisés par les attaquants. De nombreux paquets légitimes s’en servent pour compiler des modules natifs, télécharger des binaires spécifiques à une plateforme, générer des fichiers ou effectuer des étapes de configuration. Modifier le paramètre par défaut remet en cause des hypothèses qui existent depuis des années dans l’écosystème npm. C’est pourquoi ces changements de sécurité sont souvent mis en œuvre lentement. Le paramètre par défaut plus sûr est évident du point de vue de la sécurité, mais douloureux du point de vue de la compatibilité de l’écosystème. »

La sécurité augmentée 

Il a ajouté : « Le point essentiel, c’est que les gestionnaires de paquets passent d’une confiance implicite à une confiance explicite. C’est la bonne direction à prendre. Les développeurs devraient devoir approuver les dépendances autorisées à exécuter du code lors de l’installation. Mais cette approbation ne doit pas se résumer à cocher une case sans réfléchir. Les équipes doivent savoir quel paquet souhaite exécuter un script, que ce soit de manière directe ou transitive, pourquoi il est présent, et s’il a vraiment sa place dans le 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 ayant accès à des jetons, des secrets, des registres internes, des artefacts de compilation ou des 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 faciliter la prochaine étape d'une attaque », a-t-il déclaré. 

Brian Levine, consultant en cybersécurité et directeur exécutif de FormerGov, estime lui aussi que la correction de cette faille de sécurité est une très bonne chose. « Il semble que pratiquement toutes les attaques majeures visant la chaîne d’approvisionnement de ces dix dernières années aient eu le même point faible : un code qui s’exécutait automatiquement parce que l’écosystème le permettait. Le fait que npm ferme enfin cette porte par défaut était attendu depuis longtemps, mais c’est vraiment significatif. Il s’agit du gestionnaire de paquets utilisé pour des centaines de milliards de téléchargements par mois », a expliqué M. Levine. « Lorsque npm modifie ses paramètres par défaut, cela change la posture de sécurité de pratiquement tous les environnements de développement d’entreprise de la planète. C’était peut-être le dernier grand référentiel de code à encore autoriser ce type d’exécution automatisée. » Le consultant a ajouté que ce changement pourrait ne pas se limiter à combler 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 dans cette migration difficile. Le fait que les développeurs approuvent explicitement les paquets autorisés à exécuter du code et qu’ils enregistrent cette liste dans le contrôle de source constitue une forme de gouvernance de la chaîne d’approvisionnement logicielle dont de nombreuses organisations n’ont jamais disposé », note-t-il. « Cela crée un enregistrement vérifiable qui est significatif, en particulier pour les secteurs réglementés. »