This is actually goes to the point behind the http://nodesecurity.io initiative - building up the security mindedness of the node community by auditing npm modules for various vulnerabilities and making it easy to responsibly disclose vulnerabilities to module maintainers [1].
We're in the process for the first audit wave (checking for things like child_process.exec), and have already had several modules get patched.
IIRC, the npm maintainers have expressed interest at the recent node confs/meetups about incorporating security advisory information into the npm package results, to alert people about potential issues when installing modules.
I'd wager it primarily is due to market share. Why infect .001% of the Node.js community when you could infect .0001% of the PHP community.
Given that its a newer language, its likely that node.js users are more technically skilled. Few people learn node.js as their first language. In PHP for instance, we've all seen code online from novices with horrible SQL injections (...a $_GET or $_POST directly in the query).
Node.js has a lot less legacy code. (E.g. Linux has 1000s of exploits over the years, if left unpatched you're in for a bad day).
This is the kind of thing I'm more concerned about. npm is configured by default to require sudo/root to install globally. I would rather install as a regular user, like Go packages.
Yes, npm installs to a node_modules/ subdirectory. GP is off the mark. It's possible that people mistakenly use sudo with npm because the syntax is reminiscent of apt. This is absolutely not necessary.
As of version 0.3, it is recommended to run npm as root.
This allows npm to change the user identifier to the nobody
user prior to running any package build or test commands. [1]
npm modules that are used from the command line are often installed with the -g, or global switch so they can be used anywhere. Yeoman [2], for example, is installed to /usr/lib/node_modules/yo/bin/yo and owned by nobody:users on my system. While it's reassuring that these files are chowned to nobody, I confess I don't understand npm enough to tell if running it as sudo will not give modules root access in other ways to my machine.
I've worked with node for a couple years. I've used npm hundreds of times, and I can count on one hand the number of times I've used it in combination with sudo (and all but one were a mistake).
~/dev $ ls /usr/local/lib/node_modules/
jsontool npm
Every time I've used npm with sudo I've received a big warning in red to not do that.
I only use -g when installing runnables, like less, jade etc. I try very hard to reduce the number of CLI apps that I install this way (I've written several build.js scripts that use less/jade/etc as a library instead of an application) because I don't trust the npm repository (no signing, no guarantees, etc).
Please avoid -g unless installing a CLI tool. You will only end up in version hell if you install globally, which is what node_modules was designed to avoid.
Thanks for all the comments, they are very much appreciated. I'm going to write a follow-up piece soon - if you want to send me feedback directly, please feel free.
I tend to agree with the point that NPM isn't a big enough target yet to make writing subtly malicious modules worthwhile. However, I don't think that's particularly reassuring. I also suspect that more people are using SSL/TLS directly from node (and running as root) than you might think. Malware targeted at developers may well become more of a big deal in the future.
The issue is generic with most package management systems. What I really wanted to talk about was why malware is an apparent problem in some projects and 'ecosystems' and why it isn't in others. The general consensus when talking to other security researchers is that a decent package management system is vital to security. Much like the Google Play store is a key part of Android security. However, NPM (sadly) doesn't really support that hypothesis, as (when I wrote the piece) it wasn't obvious how to report bad modules.
I'd also like to applaud the work that nodesecurity.io is doing - it's a very worthwhile project.
Malware I don't know, but I know for sure that its trivial to write a DDoS tool with it.
I blew my NSP network out of the way with line-rate small packets on a low-end box which made me reconsider my dislike for node :)
I wrote something similar for PHP and it was pretty slow which was kinda surprising. C/PY/PL is fairly easy, and I only got multi-Gbps out of C, but in fairness its a lot easier in C...
Isn't this the case with any package management system. In most linux distributions it is common to be able to do (the equivelent of) "apt-get install X" just to try out X. Almost every programing language I've used had its own package manager that installs things just as simply.
Apt is probably a bad example here, as there's a fairly large amount of key verification involved in it. If you're installing from the main package repository you're pretty safe. PPAs you at least know what you're getting and that someone hasn't hijacked it.
It's the dynamic language and other ones that run untrusted code to verify or install things that you have to be worried about.
debs used in the official Debian repository are the result of a process that requires authorized developers who have been nontrivially vetted (including establishing their real-world identity) to cryptographically sign the packages with their own keys, before they are signed with the repository key. The packages also follow a strict release process that affords opportunity for malfeasance to be detected, especially in popular packages. You have a good assurance that the package is not malicious, and that if it is, someone will be accountable.
npm, pypi, and rubygems do not follow such a process. Pretty much anyone can add a package to them which might do anything.
SSL just protects against man-in-the-middle attacks.
| a package you get from apt-get can later
| install malicious code on it's own.
The package that you install using apt-get is signed, using public key cryptography. Those keys would have to be compromised for someone to upload a malicious package.
As for installed software installing malicious code, that's something that a user can do manually too. Installed software could be compromised as well.
I think you're missing the point. Security is achieved through layers of protection that an attacker must defeat in order to take a malicious action. The technologies being discussed here solve different problems:
SSL - Validates that you are actually connecting to the server represented by the URL and that no one is listening/inserting information in between.
Author signed packages - Validates that the package contains only what the author has released.
Yes, it's possible for both to be compromised with enough work, but that's the point: "with enough work". We can't prevent attacks 100%, but we can layer up security so that an attacker's chances of finding a usable exploit approach zero when looking at the full chain.
Or maybe he's been infected by a mind-control slug. Why don't we just dispense with all security since it's always possible someone might do something stupid?
npm modules require an owner with a valid username and password for npm. This user is then identified via npm. Problem management goes through Issac, the human in charge of npm.
Are you claiming that a username/password is more secure than public key cryptography? (Also, it's not like SSL hasn't been compromised before. Absolute faith in SSL isn't advisable when there is an alternative.)
Yes, and they're also signed by both the author and the package maintainers and have to go through a public review to be included in the package repository. Even for an upgrade. The whole point of that rigmarole is to provide some extra level of guarantee that they haven't been taken over by aliens.
Gems, as an alternative example, can be updated by the author (or anyone with their authentication key) at any time. They can be signed, but even if they are there's no real way to verify the authenticity of the signer.
I'm not even saying this is a bad thing. There's validity to both approaches because they prioritize different things.
Yes but we're not comparing distribution-official APT repositories with unsigned downloads, we're comparing potentially third party APT repositories with HTTPS downloads. When users add a third party repo they often don't check who the author is, who the key belongs to or whether they even obtained a legit key. In the HTTPS case, users don't check the HTTPS certificate. The end security is about the same.
> By necessity, you are also also giving it access to your domain certificates and private keys.
By necessity? I'd argue the opposite, by necessity don't do this at all or ever. Is this person terminating SSL at their node app? Because for anything but a toy that's probably a bad idea.
There are infinitely simpler targets for malware with better returns than writing a package to be used by developers in the hope you'd be able to scoop up random certs and database credentials of limited value. It is POSSIBLE your package would get installed on a server run by an organization with credentials that a malware author would care about: but unlikely, and quite frankly not worth waiting for the day when you can make more money (for example) breaking into CMS servers and distributing browser exploits.
A contagious organism needs an adequate density of susceptible hosts to survive, or a long incubation period to wait for opportunity to strike and infect a new host, effectively allowing it to perceive adequate density of hosts. Perhaps "nodejs" is not adequately prevalent, perhaps malware for it is very clever, perhaps both?
This is not about self-propagating viruses or worms, but about trojan horses in the original sense - seemingly useful but harmless modules that secretly open a backdoor to your server.
the many eyes theory might not apply as a whole, but when every contribution to a codebase has a small surface area, and goes through a github pull-request, it is thoroughly examined by at least one person, usually a handful in popular modules. It'd be much harder to slip something malicious through.
But if a popular package's author is malicious they can add bad code, push a patch release, and most packages depending on it will install it. Pull requests are easy to check. Automatically installed patch releases aren't.
Because almost all plugins will have too much code to read carefully in a reasonable amount of time. Malicious behavior such as uploading the contents of files at certain paths might take only three lines of code, and those lines could be spread out at different points in a long function, and have misleading variable names. It would take a prohibitive amount of time for a developer who just wants to use a plugin to spot such errors.
1. Reading the full source code can be quite difficult and time consuming, and being able to spot security issues is even harder. Some experts miss those until someone stumbles upon it, or is dedicated enough to look deeper...
2. there's an underlying assumption that if something is open-source, then the 'many eyes principle' applies, and someone has looked at the code. So whilst it's generally true, it might not always apply to security. Many might have looked at the code, but unless they were specifically looking for security, and were qualified enough to find the more subtle, hidden security issues - those will go unnoticed.
The general rule of thumb to look for stability indicators, applies to security to a large extent: activity on the project, number of 'stars' on github, reputation of the core committers etc. But even then there's no guarantee.
If you want to stand on shoulders of giants, you'd have to trust those giants to support you.
I was recently astounded by the sheer number of dependencies and attendant files that get downloaded when starting up a new node.js project. The notion of reading all the source is... quaint!
It would take too much time to do it yourself, and if you're no security expert you will miss vulnerabilities anyway. This project is a better answer: http://nodesecurity.io/
We're in the process for the first audit wave (checking for things like child_process.exec), and have already had several modules get patched.
IIRC, the npm maintainers have expressed interest at the recent node confs/meetups about incorporating security advisory information into the npm package results, to alert people about potential issues when installing modules.
[1] http://blog.liftsecurity.io/post/52010883123/security-md-imp...