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.
Isn't this scenario applicable there as well?
How much would it take to spread? If something like this gets added to Express or an Express dependency, I would imagine it would contaminate tens of thousands of products in one day.
I can sort of understand using JavaScript in the browser. After all, it's the only option. But server-side?! There is no such restriction!
Why the heck would anyone choose to use such an awful, crippled language when they have numerous superior options?!
It baffles my mind how somebody would go out of their way to use such an awful language when there are so many better options available.
I'm not one to pre-judge. I tried out JavaScript, Node.js and npm for myself. I couldn't believe just how awful they were! Everything about them feels like a regression compared to their competitors.
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.
Petulant developers save the internets!
Wait... there are people who run Javascript code, on a server, as root? Untrusted Javascript code they don't control to boot? Uhhh, wow.
npm as a concept seems susceptible to failures of different kinds. If I were to build a long-life system around Node.js, this could be a problem.
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.
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).
The above post is my (small) understanding of the issue. I'm sure node.js fans will point out a detail that I missed. I'm no expert on Node.js because as someone else pointed out, you use Javascript in the browser, despite it's many flaws, because you have no choice. On the server side, there are several much better options, so it would seem that only people too lazy to learn a server-side language would use Javascript on the server (or maybe some other special case).
I'm sure node.js fans will point out a detail that I missed.
Nah, they'll just copy and paste someone elses reply that they found on StackOverflow.
CPAN, PyPI, RubyGems, et al all encourage this behavior in a manner that enables a particular language developer.
Similarly, prolifiretaion of other enabling technologies (e.g. copr, ppa, etc repositories or dockerhub hosted images) have similar implications at different levels.
The thing is once upon a time, this was all a pain in the ass, to be tolerated until you would do the packaging all nice and neat. These rather nice things all came about because people didn't want to tolerate the pain in the ass of tracking all these dependencies just to get started, and suddenly pulling in some arbitrary library from the internet is not much more complex than a single include/import/use/whatever statement.
So far so good, until people stop using it as something to get started and/or something to get their personal setup going, and started advocating fast and loose references as a way of life for production setups and delivering to third parties. There's an assumption baked into all these setups that code only ever gets better over time, and it's best to get 'latest' no matter what (even in the face of who knows what attempts to change things, with bugs and interface changes and all).
XML is like violence. If it doesn't solve the problem, use more.
version numbers lockdown ftw!
I'm not a young hipster. I'm an oldie who has worked in a dozen or more languages over the years. Starting with Algol back in the day. I have worked on all kinds of systems from industrial control, safety critical avionic flight controls, CAD systems, and yes the web.
I was very surprised to find out a few years ago that the stupid Javascript language, you know that simplistic and slow scripting language use by web-monkeys to respond to mouse events and animate useless crap in the browser, is actually quite sophisticated. It has had features from the start that C++ and Java are only recently catching up with, in their clunky ways.
JS has performance. As an experiment I re-implemented a simple server side process in JS that was previously C++. Bugger me the JS version was nearly as fast, much simpler, much easier to maintain and extend. There was no going back after that, everything I do is server side JS now.
No I won't use it for serious compute intensive tasks. Bu then I would not use Java or PHP or whatever for that either. Use the right tool for the job and all that.
Yes, npm has it's problems. Yes one should not be running any random code downloaded from the net willy-nilly on ones servers. These considerations apply to all languages as far as I can tell, unless you are crafting all of your code with no dependence on external libraries or operating system.
Somebody here said testing was the answer. Sure testing is a damn good idea but really, if the is some rogue code hiding in some module the module may work perfectly well in every test you can throw at it. Until one day it is triggered and wakes up to do whatever it does.
My conclusion: JS is a great server side language. Keep you wits about you when using other peoples code.
A language is only as good as the person using it. "Better" options are just user preference, node.js is a perfectly capable back end.
But only node.js can be a total rockstar language man
http://saveie6.com/
Where's the "Why don't they use Rust" guy?
It really depends on the real audience.
What I like to do is offer two paths to download. One via a channel like CPAN or such, and as a package repository. If someone asks 'how to run the code' I say 'add this package repository (yum/apt) that we support and maintain', and there we are strict about the dependencies, mirroring, updating, and testing them. There's a dependency that sees a major release? Good for them, they aren't in the repository until they get tested. The users of the yum/apt get priority support-wise because it's much less variation to contend with and sort out.
If a developer wants to build something themselves and grabs it from the CPAN/PyPI/whathaveyou, I let them get the 'latest and greatest' knowing that they are better enabled to cope with the risk and sort through. The hope is that they would, in turn, do the appropriate effort to make a *supportable* distribution of their project, but if they don't, it's on them rather than me.
XML is like violence. If it doesn't solve the problem, use more.
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 incompetence is peeking out from your saggy-ass pants. JavaScript is no better and no worse than other programming languages in the hands of competent programmers.
Javascript is the bastard two-headed stepchild of VisualBasic and Perl, and just about as "good" as you'd expect that to be: not very. It's fine for fetching new material from a server or twiddling the DOM, but other than that, no, it's just not very good.
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.
You're not wrong, but at the same time you're not right. It's definitely possible, and even common to do things the way you say. But as the summary itself points out, that's a fault of developer choice rather than an inherent flaw. Anything released for production in any way -should- have specific version numbers set, in which case node uses those versions and the problem talked about here isn't actually a problem.
You're interfering with the Java/Spring/Maven/etc. circle jerk. Get out.