====================================================================

                             CERT-Renater

                Note d'Information No. 2016/VULN139
_____________________________________________________________________

DATE                : 29/03/2016

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running npm.

======================================================================
http://blog.npmjs.org/post/141702881055/package-install-scripts-vulnerability
http://www.kb.cert.org/vuls/id/319816
_____________________________________________________________________

     Package install scripts vulnerability

     Disclaimer: we had been told this vulnerability would be disclosed
on Monday, not Friday, so this post is a little rushed and may be
edited later.

     As disclosed to us in January and formally discussed in CERT
vulnerability note VU#319816, it is possible for a maliciously-written
npm package, when installed, to execute a script that includes itself
into a new package that it then publishes to the registry, and to other
packages owned by that user.

     npm cannot guarantee that packages available on the registry are
safe. If you see malicious code on the registry, report it to
support@npmjs.com and it will be taken down.


     How to protect yourself

     If you are installing a package that you do not trust, you can
avoid this vulnerability by running

     npm install --ignore-scripts

     If you wish to never run scripts at install time, you can instead
run

     npm config set ignore-scripts true

     Either or both of these steps will prevent you from spreading a
worm at install time.

     If you install a package that contains malicious code and then
execute it (e.g. by require()ing it into your code) it could still
perform malicious actions. You should not execute any software
downloaded from the Internet if you do not trust it, including software
downloaded from npm.


     Why does this vulnerability exist?

     Installation and other lifecycle scripts are a useful tool that
allows package authors to set up configuration, compile binary
dependencies, and perform other actions that make using npm packages 
convenient.

     On balance, it’s npm’s belief that the utility of having
installation scripts is greater than the risk of worms. This is a
tradeoff that we will continue to evaluate.


     Is this new?

     Package scripts have been a feature of npm since the very
beginning. The implications of this feature were clear from the start,
but not everyone in the ever-expanding npm community is fully aware of
them. Disclosures of this kind are helpful for that reason.


     What happens if a worm is published?

     You should report malicious packages to support@npmjs.com. Per our
terms of service, they will be taken down. Authors publishing malicious
code to the registry may be banned from the registry.

     npm monitors publish frequency. A spreading worm would set off
alarms within npm, and if a spreading worm were identified we could
halt all publishing while infected packages were identified and taken
down.


     Can npm scan packages for worms?

     npm is working with security vendors to introduce enhanced security
vulnerability scanning and mitigation services. This work is underway
but not yet ready.

     At root, it is impossible to guarantee that any new piece of
software is benign short of manually inspecting it, as mobile app
stores do. The work required to do this would be prohibitively
expensive. Instead, we rely on users to flag suspicious packages and
act quickly to remove them from the registry.


     What else can be done?

     Other potential steps can be taken to make publishing without an
author’s knowledge harder, including implementing 2-factor
authentication on publishing. This functionality is already available
via integrations in npm On-Site, and npm is working to make various
2-factor solutions available to the public registry. This work is also
not yet complete.


     What if I…

     Ultimately, if a large number of users make a concerted effort to
publish malicious packages to npm, malicious packages will be available
on npm. npm is largely a community of benevolent, helpful people, and
so the overwhelming majority of software in the registry is safe and
often useful. We hope the npm community continues to help us to keep
things that way, and we will do our best to continuously improve the
reliability and security of the registry.

_____________________________________________________________________


Vulnerability Note VU#319816

npm fails to restrict the actions of malicious npm packages

Original Release date: 25 mars 2016 | Last revised: 26 mars 2016


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.


Description

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
     Worm sets a lifecycle hook on the new npm module to execute the
worm on any install
     Worm publishes the new module to the user's npm account
     Worm 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:
npmwormdisclosure.pdfnpmwormdisclosure.pdf

The timeline provided in the above document is as follows:

     Jan 1 2016 ­­ Initial discovery of exploit
     Jan 4 2016 ­­ Initial disclosure + proof of concept to npm
     Jan 5 2016 ­ ­ Private disclosure to Facebook
     Jan 7 2016 ­­ Response from npm
     Jan 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.


Solution

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:

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
Use npminstall someModule --ignore-scripts


Vendor Information (Learn More)

Vendor	Status	Date Notified	Date Updated
npm	Affected	11 Feb 2016	25 Mar 2016

If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)
Group 	        Score 	Vector
Base 	        6,0 	AV:N/AC:M/Au:S/C:P/I:P/A:P
Temporal 	5,1 	E:POC/RL:W/RC:C
Environmental 	3,8 	CDP:ND/TD:M/CR:ND/IR:ND/AR:ND

References

 
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


Credit

Thanks to David Ross and Sam Saccone for reporting this vulnerability.

This document was written by Will Dormann.


Other Information

     CVE IDs: Unknown
     Date Public: 25 mars 2016
     Date First Published: 25 mars 2016
     Date Last Updated: 26 mars 2016
     Document Revision: 44

Feedback

If you have feedback, comments, or additional information about this
vulnerability, please send us email.


==========================================================
Serveur de référence du CERT-Renater
https://services.renater.fr/ssi/
==========================================================
+ CERT-RENATER          | tel : 01-53-94-20-44           +
+ 23 - 25 Rue Daviel    | fax : 01-53-94-20-41           +
+ 75013 Paris           | email: cert@support.renater.fr +
==========================================================