I went straight to the comments on this HN submission because I knew NPM couldn't just be good guys.

agreed for the most part. "Foiled" is pretty much the wrong word here. Maybe "Detected and halted further loss..."

That's wrong too.

What they did was to allow komodo to, vigilante style, outright steal the coins, and hold them hostage until you entertain them with proof of ownership/identity and whatever other ridiculous requirements they come up with.

But it's npm and kleptocurrency. Nothing of value lost.

> kleptocurrency

Love that!

trying to make that catch since 2013 :D

Hm... to claim the coins they saved, you have to receive and send a small transaction from the compromised wallet to verify ownership. But how do they make sure that it's not claimed by the hackers who may have the seed of these wallets? The only thing they say is that they don't send it if there is multiply claims (probably one from hacker and one from real owner).

I’m honestly amazed this hasn’t happened more often; it’s ridiculous that a developer has to install thousands of lines of code to create a simple “hello world” website.

Guess someone slipped you a wrong thing instead of Node, because for me, about five lines and zero dependencies work fine.

Probably confused node and react.

Maybe the post has been edited, but just now it reads '"hello-world" website'. When I search for "create a website with node.js" the top results all talk about using Express.js.

If I `npm init` and then `npm install express` as suggested, the result is 50 packages installed containing 21707 lines of javascript.

edit: trying to show what people are steered towards when looking up how to do this themselves.

React is a better example:

https://twitter.com/dylanbeattie/status/1098204272653676544?...

"Before you even open a text editor, your project contains 1.5 million lines of code. Most of it contributed by volunteers and enthusiasts. No formal review or release process."

I feel that this isn't quite a fair comparison.

Take any other language with a web framework---Ruby with Rails, Java with Play/Spring, any web server which exposes a CGI interface, Python with Django/flask/whatever---and you will find a colossal amount of framework code behind the simple "hello, world!" demo.

Web apps are complex things, especially when the framework has to account for common cross-cutting concerns and patterns elegantly and succinctly. The fact that the JS ecosystem with NPM exposes that complexity to the user directly with an (albeit massive) node_modules installation isn't a strike against node per se: other languages have this code too, they just don't stash it all in the same folder as your project.

If you want to criticize the JS ecosystem, doing it on the basis of sheer SLOC downloaded by an `npm install` isn't too great.

We can talk about the quality of these packages, or about code review standards, or about the unique challenges auditing code from many sources for bugs and security problems. But talking about how the framework code gets installed seems counterproductive.

No need to repeat what others said, but I'll also note that create-react-app is a website boilerplate generator and includes preconfiguration for tons of stuff including test frameworks etc.

So yes, before you even open a text editor, you have eslint, jest, typescript etc all set up. Duh-doy, that's a lot of lines of code.

Sigh…

A terrible argument given that React is a Facebook project, initially built and shipped by only Facebook employees, not random volunteers.

[citation needed]

I don’t think it’s fair to single npm out here. The truth is any package manager that lets anyone publish package updates is vulnerable to this type of attack.

NPM has, specifically and deliberately, played down the successful theft here, making out that they completely foiled it.

If they hadn't done such a scummy, corporate spin job on this, I'd be inclined to agree with you - but they did.

npm encourages an auto-upgrading versioning scheme: take version x or higher.

It's great for keeping dependencies up-to-date, but this makes it immensely vulnerable to the kind of malware injection, as publishing a library version with payload will immediately propagate throughout the ecosystem.

In most other version managers (e.g. maven) every library and application specifies a hard-coded version, which requires users to manually upgrade, giving a window were a malicious version can be detected before it affects anyone.

For a security critical app not locking down the dependencies to audited versions seems very dangerous indeed and I believe there is some blame to be had there

You’re still vulnerable if you lock down dependencies during the period the malicious code is wild though. You have to actually audit your locked dependencies to consider yourself safe.

Isn't that expecting the car to be invented before the wheel?

From what I've seen, quite a few of these have been targetted attacks - the assailants have targetted specific variables that existed in a specific codebase that they knew imports their module. Of course, if you've only just started writing that codebase, your dependencies have no way of knowing where you're storing private keys (short of somehow scanning the object space for variable names like "private_key")

But yes, in theory I would love for any *-sensitive code to go through a thorough audit after every dependency update before a version gets released in the wild. I'm guessing that next-to-nobody has the resources for that kind of an effort though.

In this case, though, someone explicitly changed the included version to the malicious one.

This same thing is done anywhere semver is used or any other version range system. This includes python, rust, go, and many more.

Go's official package management solution actually only fetches the minimum specified version of each dependency. So auto-upgrades never happen except when you explicitly update a dependency to a newer version.

NPM isn't being singled out as part of a hypothetical risk analysis, this is about an attack that actually happened via NPM.

Semver probably makes the problem worse though.

how?

Dependency ranges mean package updates happen automatically. So a minor release could contain malicious code without anyone noticing. I still think semver is worthwhile even if it a little bit more vulnerable to this kind of attack.

Yeah, but a dependency attack is a rarer issue than out-of-date dependencies that contain known security vulnerabilities.

Because if you don't consider SemVer as part of your threat model, you'll specify "v1.2.3 or above" instead of "v1.2.3".