As an example, the PhoneGap project has 463 transitive dependencies, of which 276 individual NPM accounts can push new versions of those packages. It would take only one person out of the 276 to install a package containing the worm to infect everyone who'd ever installed the PhoneGap project, Saccone said.
NPM shrugs off the risks
While there is currently no fix for the vulnerability, the CERT Vulnerability Note from the United States Computer Emergency Readiness Team outlines several workarounds. They include using the
-ignore-scripts option when installing modules, locking down dependencies with NPM shrinkwrap, and encouraging users who own modules to regularly log out of NPM.
Organizations using NPM in their environments should run a local mirror of the NPM registry and prevent individual users from installing directly from the main registry. This way, organizations can regularly audit the local registry and make sure malicious files have not been inserted into the package's dependency list.
Saccone recommended NPM expire the login tokens to force users to log in after a certain period. In the blog post, the team did not address the recommendation, but outlined other avenues they are exploring to mitigate the risk.
One such idea is to make it more difficult to publish without the module owner's awareness, such as by requiring two-factor authentication. Another option is to work with security companies to offer vulnerability scanning for modules, but that is not available at the moment. The team currently monitors publish frequency, so a worm would be detected because it was publishing a lot of new versions, but for the most part, NPM relies on users to report suspicious packages.
"Ultimately, if a large number of users make a concerted effort to publish malicious packages to NPM, malicious packages will be available on NPM," the blog post said.
Trust, but verify
It hasn't been a good few days for NPM, as the vulnerability disclosure comes on the heels of the current debate on how the package manager should handle unpublished modules. A developer unpublished a small package from NPM last week and inadvertently caused many other projects who relied on that package to break. People also realized how easy it would be for someone else to register their own code with the name of the unpublished modules. Anyone who grabbed the package names would be able to install the code onto any user who had installed the original package.
There have been a number of discussions on Reddit and GitHub over the past few days discussing NPM's heavy reliance on trust -- that package maintainers will keep the packages they write, and no one is writing malicious code. In a global ecosystem, that is a dangerous assumption, because only one person needs to act against the interests of the community to break a lot of code. There must be a way to safely install NPM modules, such as using package signing or another method to verify that the code is safe and from the correct source. Until there is one, developers are left with the unsettling realization that they are taking a huge risk every time they run NPM install.
Sign up for CIO Asia eNewsletters.