Slashdot Mirror
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.
Said otherwise:
Because the new generation wants fully-automatic updates, without a care for security at all. They won't even pay someone else to do it manually regularly.
Plus it's great for targeted infection of people deemed dangerous to the "rich and powerful", without having to mess with the network.
I don't think this is really applicable to any other language. With any other language, since roughly the 1950s, standard practice has been to test code, often in two or three steps, THEN deploy it to production after your developers and your QA team have signed off on it.
With Javascript and node.js, you declare the name of some external package you'll use and it constantly fetches the newest version, with the newest bugs, directly onto production. You never see, never mind test, the code before it runs on your production systems. With any other language, you'd upgrade production to a known, vetted version only occasionally. If there was an issue the community hadn't already caught, hopefully you would catch problems in testing.
We saw a similar problem last week - somebody removed their package from the repository and that broke everyone's production systems.
This approach may sound insane. Because it is.
Javascript has some terribly bad parts (as does perl and php) and I would concur that languages like Python/Ruby seemed to be planned in entirety a bit more. I would recommend looking at ES2015+, the next revision of the Javascript. It does a lot to curb those issues (JS actually has a "strict" mode that handles some of the gotchas), and ES2015 adds proper module support, as well as a standard class syntax.
These features have been in use for years by transpilers (to cover the gap between agreement on a new language feature and the time before it is adopted by the runtimes). Typescript is an even more powerful extension of ES2015 that adds compile-time type analysis/verification but generates nearly perfect idiomatic ES2015 code.
je suis parce que j'aime
Capable, yes, in that it executes code, the best option, pretty much never.
I take a polyglot approach to backend development and I've yet to find a case where node.js was actually the best tool. This is not user preference, this is understanding the tools you use. I've yet to find anyone using node.js who is competant in more than just javascript.
Your comments read like a confused mess. It saddens me they have both been modded so highly. But ill informed JS hate has always ridden high in these parts.
Firstly, neither Javascript nor Node do anything you describe, and laying the accusations solely at the feet of Javascript itself is just laughable. Like blaming paper for having had a bad novel printed on it. Javascript is just code, a bunch of text files sitting in a directory. Node processes/runs that code when you tell it to. It'll either exit out on completion or keep going if that's what you've set up your code to do. That's it.
The problems you describe are with a third entity, Node Package Manager (NPM) which, while now included with Node, is not Node, does not run when Node does and is merely a tool you can choose to use (or, apparently, abuse) as you see fit to install and manage external (or even internal) packages. Those packages in turn are again just Javascript - text files sitting in a directory that will be processed by Node if your code calls that dependency.
I have no desire to explain out further basics of NPM, but needless to say my experience has been, of course, entirely different to what you describe. NPM is not some rampaging beast updating shit behind your back without telling you (unless you actually are running NPM directly on your production servers - in which case, shame on you). The symptoms you describe actually suggest the opposite. Someone changed the packages.json file and everyone else failed to run npm to update the local packages to match after getting latest. So you all went out of sync with whoever made that change. That's a failure in your deployment and testing strategies, nothing more.