Where is all the Node.js malware?

http://www.cs.ox.ac.uk/blogs/sss/2013/04/02/why-isnt-there-any-nodejs-malware/

by reedlaw • 13 years ago

57 46 13 years ago

cs.ox.ac.uk

seppo00102• 13 years ago

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

cnp• 13 years ago

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

rmoriz• 13 years ago

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

pudquick• 13 years ago

Python does have a relatively easy to find page regarding reporting security issues:

https://pypi.python.org/security

I was not (easily) able to find something similar for ruby gems.

gizmo686• 13 years ago

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.

stormbrew3• 13 years ago

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.

ricardobeat3• 13 years ago

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.

jjtheblunt• 13 years ago

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• 13 years ago

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.

imissmyjuno• 13 years ago

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

gingerlime• 13 years ago

laziness? :)

more seriously:

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.

roryokane• 13 years ago

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.

louischatriot• 13 years ago

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/

damon_c• 13 years ago

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!

cobookman• 13 years ago

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

stormbrew3• 13 years ago

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

prezjordan• 13 years ago

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

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

reedlaw3• 13 years ago

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.

seppo00102• 13 years ago

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

threepointone• 13 years ago

I do believe you're mistaken. It might have done so in the past, but pretty certain it doesn't require sudo anymore.

deelowe• 13 years ago

This is absolutely not true.

lancestout• 13 years ago

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

ricardobeat3• 13 years ago

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• 13 years ago

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.

bifrost• 13 years ago

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

jacques_chester• 13 years ago

Where is all the FreeBSD malware?

jdoss• 13 years ago

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

agilebyte• 13 years ago

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.

fomojola• 13 years ago

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.

jplyle• 13 years ago

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

Where is all the Node.js malware?

Related Stories