New Attack Discovered On Node.js Package Manager npm (softpedia.com)

An anonymous reader writes: A Google researcher has discovered a way in which he could exploit some npm registry design flaws to propagate a malicious package to other packages, and in the projects that load them. The exploit leverages things such as npm's persistent authentication, developers who never lock down dependencies (and often use version number ranges), npm lifecycle scripts that run with the user's privileges (sometimes as root), and npm's centralized registry, which doesn't review or scan code. Attackers can compromise other projects with malicious code, can compromise Node apps used in corporate environments, or they can launch worm-like viruses that poison npm packages at random.

Comments

How do we know it hasn't already?

[Anonymous Coward]

How do we know that such techniques haven't already been used?

Even if they fix these flaws, I think every single line of code in every single version of every single npm package will need to be reviewed by a team of security experts.

Re:Why would anyone use JavaScript?!

[i.r.id10t]

Aside from that, why are libraries pulled in dynamically from the intertoobs on a production server? Why aren't the libraries packaged like Perl CPAN stuff, or PHP PEAR stuff, to be downloaded (and signature verified?) to the server or dev machine and accessed only locally? Heck a tar.gz file with a posted list of hash sums would be more secure. This is all old hat stuff that has been solved in multiple ways, no reason at all for it to be an issue now.

Javascript and security?

[Anonymous Coward]

Wait... there are people who run Javascript code, on a server, as root? Untrusted Javascript code they don't control to boot? Uhhh, wow.

Re:Javascript and security?

[El_Muerte_TDS]

wget -O- https://example.org/install.sh | sh

is a very common installation method presented by various tools (or via curl). In most cases you even need to run them as root due to the fact that the creators of those tools do not understand how to have their software work as non-root users.

For example:
https://toolbelt.heroku.com/de...
https://docs.docker.com/linux/...
https://nodejs.org/en/download...

Re:Javascript and security?

[Anonymous Coward]

I tend to see "curl" more often than "wget -O-", but it's the same problem.

And when a software project recommends

curl (some url) | sh

I assume that the developers arrogant or incompetent.

When the project recommends

curl (some url) | sudo sh

I assume that the developers are incompetent or malicious.

But I'm a greybeard.

The sad thing is that I've met bright, young developers who don't see it as a problem. "That's how the Internet works," they say, pointing at Javascript on the web. (I grind my teeth at JS+HTTP == web == Internet, but that's a separate issue.)

After all, if your customers have enabled Javascript, they've already given up the idea of curating the code that runs on their system. There's no review, approval, QA, or audit trail. And if your customer base is okay with that (as 99% of the technical folks seem to be), why should you be the one to take on the additional work?

And once your organization is okay with that thinking, then the curl/wget thing follows naturally. Same mindset and acceptance of risk.

After all, being careful will just slow you down and let your competitor beat you in the market.

It's almost enough to make one cheer the blackhats.

The issue with dep managers and version wildcards

[Anonymous Coward]

I argue this with other devs a lot. Dependency managers, *especially* if you use version wildcards, are asking for trouble. Keep more of a handle on what your dependencies are, and only move versions if there's a compelling reason (security update, huge performance boost, etc).