
Where is all the Node.js malware? - reedlaw
http://www.cs.ox.ac.uk/blogs/sss/2013/04/02/why-isnt-there-any-nodejs-malware/
======
lancestout
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.

[1] [http://blog.liftsecurity.io/post/52010883123/security-md-
imp...](http://blog.liftsecurity.io/post/52010883123/security-md-improved-
security-disclosure)

------
cobookman
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).

------
agilebyte
Many (most?) packages are on GitHub. If one is popular with the community, I
am less likely to believe it is a malware.

<http://eirikb.github.io/nipster/>

For now, the ease at which we can build npm modules allows the ecosystem to
grow. When it gets popular, we can rethink our approach.

------
seppo0010
Is there any difference with Python and PIP, or Ruby and gems?

~~~
cnp
Yes, there is a difference: there's been a ton of malware released on both.

~~~
rmoriz
Can you name some? I'm only aware of the single rubygem.org-issue…

------
prezjordan
It happened once (by accident) on the popular "n" package.

<https://github.com/visionmedia/n/issues/86>

~~~
reedlaw
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.

~~~
seppo0010
Isn't npm default ./node_modules?

    
    
        $ npm install socket.io
        socket.io@0.9.14 node_modules/socket.io
        ├── base64id@0.1.0
        ├── policyfile@0.0.4
        ├── redis@0.7.3
        └── socket.io-client@0.9.11 (xmlhttprequest@1.4.2, uglify-js@1.2.5, active-x-obfuscator@0.0.1, ws@0.4.25)
        $ ls
        node_modules

~~~
pork
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.

~~~
reedlaw

      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.

1\. <https://npmjs.org/doc/README.html>

2\. <http://yeoman.io/>

~~~
dmpk2k
That's odd.

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.

~~~
reedlaw
Which version are you using? And do you install packages globally using the -g
switch?

~~~
dmpk2k
Currently 1.2.11. As you can see above, I've only ever installed one package
globally (jsontool).

------
jplyle
Hi all,

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.

Best wishes,

John

------
bifrost
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...

------
gizmo686
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.

~~~
stormbrew
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.

~~~
ricardobeat
npm uses https by default. The risk is the same, a package you get from apt-
get can later install malicious code on it's own.

~~~
pyre

      | npm uses https by default
    

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.

~~~
ricardobeat
Or the publisher's machine has been compromised. Or maybe he accepted a
malicious patch. I don't see any difference here.

~~~
bradleyland
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.

------
stormbrew
> 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.

------
fomojola
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.

------
jjtheblunt
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?

~~~
brazzy
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.

------
ricardobeat
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.

~~~
curiousdannii
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.

------
imissmyjuno
Why not read the source of whatever you're using before running it?

~~~
roryokane
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.

------
jacques_chester
Where is all the FreeBSD malware?

~~~
jdoss
Screw FreeBSD... where is all of the NetBSD malware???

