{"vuid":"VU#319816","idnumber":"319816","name":"npm fails to restrict the actions of malicious npm packages","keywords":["npm","lifecycle scripts","shrinkwrap","Node.js"],"overview":"npm allows packages to take actions that could result in a malicious npm package author to create a worm that spreads across the majority of the npm ecosystem.","clean_desc":"npm is the default package manager for Node.js, which is a runtime environment for developing server-side web applications. There are several factors in the npm system that could allow for a worm to compromise the majority of the npm ecosystem: npm encourages the use of semver, or semantic versioning. With semver, dependencies are not locked to a certain version by default. For any dependency of a package, the dependency author can push a new version of the package. npm utilizes persistent authentication to the npm server. Once a user is logged in to npm, they are not logged out until they manually do so. Any user who is currently logged in and types npm install may allow any module to execute arbitrary publish commands. npm utilizes a centralized registry, which is utilized by the majority of the Node.js ecosystem. Typing npm publish ships your code to this registry server, where it can be installed by anyone. When these three aspects of npm are combined, it provides the capability for a self-replicating worm. The following steps are an example worm workflow outlined in the report provided by Sam Saccone: Socially engineer a npm module owner to npm install an infected module on their system. Worm creates a new npm module\nWorm sets a lifecycle hook on the new npm module to execute the worm on any install\nWorm publishes the new module to the user's npm account\nWorm walks all of the user’s owned npm modules (with publish permissions) and adds the new module as a dependency in each's package.json. Worm publishes new versions to each of the owned modules with a “bugfix” level semver bump. This ensures the majority of dependent modules using the  ^ or  ~ signifier will include the self­replicating module during the next install. The full report from Sam Saccone is available here in PDF form: The timeline provided in the above document is as follows: Jan 1 2016 ­­ Initial discovery of exploit\nJan 4 2016 ­­ Initial disclosure + proof of concept to npm\nJan 5 2016 ­ ­ Private disclosure to Facebook\nJan 7 2016 ­­ Response from npm\nJan 8 2016 ­­ Confirmation of works as intended no intention to fix at the moment from npm. Feb 5 2016 ­­ Shared the disclosure doc","impact":"An attacker may be able to create a self-replicating worm that spreads as users install packages.","resolution":"The CERT/CC is currently unaware of a practical solution to this problem. Please see the npm Blog for details and also consider the following workarounds:","workarounds":"As a user who owns modules you should not stay logged into npm. (Easily enough, npm logout and  npmlogin) Use  npm shrinkwrap to lock down your dependencies\nUse  npminstall someModule --ignore-scripts","sysaffected":"","thanks":"Thanks to David Ross and Sam Saccone for reporting this vulnerability.","author":"This document was written by Will Dormann.","public":["http://blog.npmjs.org/post/141702881055/package-install-scripts-vulnerability","https://www.npmjs.com/","https://nodejs.org/en/","https://docs.npmjs.com/getting-started/semantic-versioning","https://docs.npmjs.com/cli/shrinkwrap","https://github.com/joaojeronimo/rimrafall","https://blog.liftsecurity.io/2015/01/27/amaliciousmoduleonnpm","https://medium.com/@nm_johnson/npm-package-hijacking-from-the-hijackers-perspective-af0c48ab9922","https://github.com/contolini/pizza-party"],"cveids":[""],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2016-02-09T17:24:20Z","publicdate":"2016-03-25T00:00:00Z","datefirstpublished":"2016-03-26T03:37:50Z","dateupdated":"2016-03-26T21:46:51Z","revision":46,"vrda_d1_directreport":"1","vrda_d1_population":"2","vrda_d1_impact":"4","cam_widelyknown":"0","cam_exploitation":"0","cam_internetinfrastructure":"0","cam_population":"0","cam_impact":"0","cam_easeofexploitation":"0","cam_attackeraccessrequired":"0","cam_scorecurrent":"0","cam_scorecurrentwidelyknown":"0","cam_scorecurrentwidelyknownexploited":"0","ipprotocol":"","cvss_accessvector":"N","cvss_accesscomplexity":"M","cvss_authentication":null,"cvss_confidentialityimpact":"P","cvss_integrityimpact":"P","cvss_availabilityimpact":"P","cvss_exploitablity":null,"cvss_remediationlevel":"W","cvss_reportconfidence":"C","cvss_collateraldamagepotential":"ND","cvss_targetdistribution":"M","cvss_securityrequirementscr":"ND","cvss_securityrequirementsir":"ND","cvss_securityrequirementsar":"ND","cvss_basescore":"6","cvss_basevector":"AV:N/AC:M/Au:S/C:P/I:P/A:P","cvss_temporalscore":"5.1","cvss_environmentalscore":"3.84489471202594","cvss_environmentalvector":"CDP:ND/TD:M/CR:ND/IR:ND/AR:ND","metric":0.0,"vulnote":null}