NPM swats path traversal bug that lets evil packages modify, steal files. That's bad for JavaScript crypto-wallets

On Wednesday, NPM, Inc, the California-based biz that has taken it upon itself to organize the world's JavaScript packages into the npm registry, warned that its command line tool, the npm CLI, has a rather serious security vulnerability. Version 6.13.4 has been rushed out with a fix. The flaw – also present in less-than- …

[Mike 137]

"...JavaScript crypto wallets..."

Anyone who uses javascript for anything remotely sensitive or "secure" should be taken out, have their head examined and be barred from ever programming again. Client side code with no verification or security model can be tampered with absolutely anywhere, not just in the repository. Javascript is the primary vector for almost all online host compromises, so it's inherently lethal.

[Pascal Monett]

Which is why I only use browsers that have an add-on that can block JS from executing. When I use Chrome (which I have to for business reasons), it is only to go to a very limited selection of sites.

I only allow JS to execute on sites I trust. The others can go fudge themselves.

[Anonymous Coward]

> The others can go fudge themselves.

Damn right, what a bunch of muddy fudgers!

[OldSoCalCoder]

Re: "...JavaScript crypto wallets..."

Isn't node.js server side javascript? Don't you want to use that ultra-bitchin language everywhere? C'mon, a simple jobs search will tell you "everyone" is building their critical applications using javascript everywhere. And, according to one website,

"Node.js frameworks are mostly used because of their productivity, scalability and speed, making them one of the first choice for building enterprise applications for companies."

Doesn't that make you feel better?

[sabroni]

Re: Anyone who uses javascript for anything...

Are you saying that computers behave unpredictably when running JavaScript? Or that it is impossible to test JavaScript? Or just that you don't work with it, don't understand it and are therefore frightened of it? It sounds like you think nodejs runs in the browser....

Your last point could be extended to read "http is the primary vector for almost all online host compromises". Should we get rid of that too?

People on tech sites who parade their ignorance of something like it's a badge of honour do my head in. Much like the Linux heads who can't bring themselves to consider that an engineer who works for ms could have a good idea or write elegant code.

I agree npm is a security nightmare. The problem is having to trust other people's code not the language that code is in. If your language can do useful stuff then it can be made to do malicious stuff.

[Anonymous Coward]

Re: "...JavaScript crypto wallets..."

I recently started work at a new place. They are involved in a lot of cloud based nodejs deployments. I mentioned how some people say it can't be used for real work. Person opposite told me they were working on something for air traffic control. In nodejs.

With comprehensive test coverage and properly air gapped, why not?

[teknopaul]

Re: "...JavaScript crypto wallets..."

"Javascript is the primary vector for almost all online host compromises, so it's inherently lethal."

This is plain incorrect, you don't download the JavaScript code from over the Internet from an untrusted source with nodejs.

Nodejs code is nothing like browser JavaScript, totally different security model. It is no better or worse than other scripting languages like Python or bash. The security model relies on not running code you don't trust; in a browser you do that all day.

JavaScript is arguably a lot safer than writing server side code in C or C++. I doubt there are many, if any, JavaScript compromises in any of the major browsers. If you want to pwn a browser you would be looking at the C code in the browser itself, the v8 vm, or of course the native plugins like flash.

You will not get very far trying to hack a browser in JavaScript. Its inherently safe.

[Michael Wojcik]

Re: "...JavaScript crypto wallets..."

You will not get very far trying to hack a browser in JavaScript. Its inherently safe.

And you were doing so well, too. Well, you were doing fairly well. OK, you were more or less correct in your first couple of paragraphs. After that you fell off a cliff. (Though without some world-wide low-latency easy way of searching for information, how could you have found out how very wrong you are? If only you had access to such a thing...)

Nothing ensures that Javascript (ECMAScript) engines are secure. In fact, quite the opposite is true: they're sufficiently complex that it's infeasible, indeed almost impossible, to make them free of security-sensitive vulnerabilities.

The security of the ECMAScript language is irrelevant here. It's a question of the security of the language implementation. And there are some documented problems in ECMAScript implementations.

[phuzz]

Given that you can't just fire up calc.exe like on Windows, how do Linux hackers show off their proof-of-concepts?

[stiine]

/usr/bin/rm -rf /&

[GnuTzu]

:(){ :|:&; };:

Oh, there's an access problem with that rm. Try: sudo /usr/bin/rm -rf /&

But, creds for the &. Shall we also nohup?

[Anonymous Coward]

rm -rf /

It's fun. Once did this on a computer we were using (Solaris based). Ran that command to see what would happen.

It actually stayed running for a fair while - it was more like HAL in 2001 - eventually stopped working. Very impressive resilience to having the root files removed.

[Michael Wojcik]

how do Linux hackers show off their proof-of-concepts?

I assume this is a joke, but: For command-line exploits (the best kind of exploits), running "id" is the classic, if you're demonstrating an elevation-of-privilege. For an RCE, opening a remote shell via netcat or similar is popular. Of course there are much fancier PoCs, as featured in hacker forums such as PoC||GTFO, which specializes in polyglots and cramming unexpected applications into unusual places (e.g. video games in bootloaders).

If someone wants an homage to Windows PoCs and they know X is running, they could try starting xcalc.

[GnuTzu]

Anyone Keeping Count?

How many this year?

As much as I like NPM, these things need to be gotten under control.

[YetAnotherJoeBlow]

At this point in life...

I am glad that I make policy instead of following it. None of my clients use nodejs - they are smarter than letting all-comers inject code into their repositories. I wouldn't service the customer as I wouldn't want to take the blame when ransom ware strikes. My livelihood depends on that.

[Michael Wojcik]

Re: At this point in life...

I don't use Node.js (is it really that hard to write it correctly?), but if I did, I wouldn't let "all-comers [sic] inject code into [my] repositories". That's not a requirement.

[chuBb.]

Lol oh dear

Didn't even have to wait the 6 months I predicted for a "good" (bad) vuln to show how stupid the paylink they plan to add is.

This vuln would make it possible to rewrite the project donation link in all Npm modules you installed on your dev machine, and that's about the most benign exploit of this vuln.

Personally never been sold on node, always seen it as a safe haven for Ruby on rails devs to up skill to, and for php hacks to unleash new levels of "wtf derp why do that with arrays, just use a proper language with curly braces, strong typing and an inheritance model that's fit for purpose" while it's quite nippy for simple things I mainly see it being used to provide websockets cus apache or nginx config is too hard (it isn't but meh attention span and not being shiny enough, and a generation inspired by farce books dev attitude I guess)

[ysth]

Wait, what?

npm does not keep, at least as backups, historic versions of all packages? That's...not how a package manager is supposed to be. Security issues like this are just one of many important reasons to be able to check what was distributed in the past.

[TeeCee]

...Facebook-spawned open-source alternative client...

If there were a Bingo card for fuckups, that's a house right there.