New Attack Discovered On Node.js Package Manager npm (softpedia.com) 90
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.
Not really. Javascript breaks production (Score:5, Interesting)
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.
* to the best of my understanding. Details may be (Score:5, Informative)
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).
Re:* to the best of my understanding. Details may (Score:4, Funny)
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.
Re: (Score:2, Interesting)
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.
Re: * to the best of my understanding. Details may (Score:3)
But only node.js can be a total rockstar language [youtu.be] man
Re:* to the best of my understanding. Details may (Score:4, Interesting)
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.
Re: (Score:2)
That's not really an issue for something like Maven because:
A) Maven doesn't run arbitrary code as part of the installation process
B) If you modify a library you downloaded in Maven, the library won't get re-uploaded again for everyone else to download immediately. Maven doesn't really have
Re: (Score:2)
Re: (Score:1)
Maven has the same problem in the SNAPSHOT dependencies, ...This makes maven just as susceptible with one major caveat. There are multiple federated repositories and publishing to one of those repositories requires reputation, and hosting your own repository (without reputation) is like downloading untrusted APKs on Android.
So, Maven suffers from the exact same problem? Great, glad we cleared that up, since "trust" for this type of crap just isn't good enough. It's why even when I have to use Maven as an ineffective build tool, the dependencies are all loaded onto a private repository that trusts no one and has no external connections. Why on earth would I trust my codebase to outside third parties?
Re: (Score:2)
Re: (Score:1)
Not specific to Javascript (Score:3)
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
Re: (Score:1)
Not really. Every module in CPAN have test that are automatically executed by cpan before being install (make test), also it doesn't force you to update anything if the module doesn't requiere the latest STABLE version of its dependencies which often it doesn't because Perl is a relatively stable language (unlike say, Ruby on Rails).
Re: (Score:2)
have test that are automatically executed by cpan before being install (make test)
most, not all. Additionally, unit tests are not going to be perfect. Particularly since it is a self-test. If they are being used in some way they don't realize, the tests may miss something. Ditto for applying the 'STABLE' moniker. A developer can go nuts and call it 'STABLE'.
Things in CPAN are just as capable as anything else at screwing up downstream users, and I have seen it bite folks. Due to longevity, things in CPAN are a bit more likely to be utterly stagnant compared to npm, which is a pretty
Re: (Score:3)
It's not like they assigned themselves that score. He needn't justify shit for you.
Re: (Score:1)
Ray, you are understanding the mechanics of it correctly, but the issue is that npm isn't something you _should be using on a production system in order to pull in code. you're correct, its insane to do that. as, imo, its insane to blame the tool for the antics of its users.
getting all the fiddly bits of a node.js app into the right places so that you can run and/or build multiple apps with different versions of packages pretty much means (ass-u-me-s?) that you want to do your testing/review in such a way t
Re: (Score:2)
"Insane" indeed. Nobody with at east a shred of understanding for software-engineering would ever do such a thing. It explains a lot about the broken nature of most JavaScript though.
Re: (Score:2)
Re: (Score:3)
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.
As a Software QA test intern, I found a crash bug on the test server that I could easily reproduced 100% of the time. My manager could not no matter how many times I showed him how to do so. Since he couldn't reproduce it all, he signed off the update to the production servers. The bug crashed the production servers immediately. The engineers discovered a deep flaw in the code, pulled the production servers offline for three days, and the company lost $250K in revenues. My internship wasn't renewed and I wa
Re: (Score:2)
My internship wasn't renewed and I wasn't hired full time (much to the disappointment of my manager). One-third of the staff got laid off a month after I left so the company could recover the lost revenues. That started a death spiral for the project.
You dodged a bullet. I just hope you have a decent job now.
Re: (Score:2)
You dodged a bullet. I just hope you have a decent job now.
The internship was 20 years ago. I didn't dodge the Great Recession, where I was out of work for two years, underemployed for six months (working 20 hours per month), and filed for Chapter Seven bankruptcy. I'm in my second year of government IT and the prime contract is fully funded for the next three years.
Re: (Score:1)
With Javascript and node.js, you declare the name of some external package you'll use and it constantly fetches the newest version
Wrong. With Javascript and Node.js you can use the "require" function to load packages that you have already installed (per project or globally), but it doesn't fetch anything from the Internet for you. That's what tools such as npm are for.
While npm is bundled with Node.js, but using Javascript and Node.js doesn't magically cause npm to be used. If you don't want to use it then don't use it.
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.
That's actually how it works with npm too. Use npm install to fetch the dependencies you want to use (which recursive
Re: Not really. Javascript breaks production (Score:3)
What can happen is including npm install as part of your deployment process. Depending on how tightly you specify your dependencies this could result in packages getting updated to versions that have not been tested with your code by simply redeploying (or maybe somebody has put this in as part of the flex up process, so you end up with new app servers with slightly different code than older app servers.
There are many ways to solve this, but it can get overlooked until you get bitten in the ass and deploy
Re: (Score:2)
In my opinion, JavaScript is Lisp reinvented very badly. That it is so popular and important as a programming language says something interesting about how standards emerge. I was starting to feel that this opinion just showed how out of touch I was with things, but the recent issues with NPM seem to show a serious lack of insight or experience in the communities pushing js on the server side. I can't believe there are so many seemingly competent developers advocating that it is a good thing to have package
Re: (Score:2)
Its worth pointing out that when you pull in a package from npm, there is no guarantee that its the package you expected to pull in. We also saw this week that the npm administrator is perfectly happy to change the package that's represented by a particular name.
time to spread? (Score:1)
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.
How do we know it hasn't already? (Score:4, Insightful)
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: (Score:2)
Re: (Score:2)
Why would anyone use JavaScript?! (Score:2, Funny)
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!
Re: (Score:3, Informative)
Because cheap code monkeys cannot write real code.
Re: (Score:3)
Because cheap code monkeys cannot write real code.
Sad, but true. We do not have to few coders. We have far too many and most of them bad.
Re: (Score:2)
Re:Why would anyone use JavaScript?! (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
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.
Re: (Score:2)
With a few exceptions, namely being the myriad choices available today that were not available not so very long ago.
Re: (Score:2)
I know how to use a hammer, therefore everything is a nail.
As someone who worked 20+ years in Silicon Valley from software testing to help desk to computer security, the hammer as a solution to all my problems is one of my greatest weakness. I'm constantly asking myself how I can do my job better to avoid using the hammer, especially when the hammer have proven itself to be less effective over time. Most people don't want to change, keep hammering away at the problems, and wonder why they're making less money.
Re: (Score:2)
The problem being is that they use the other repositories in the same way. Sure you *can* download and go, but overwhelmingly, people use the automated install.
Meaning that if people 'pip install' a package of mine that has a dependency, the chances are that my dependencies are such that you'll get latest of 'whatever' without verification and potentially without any test.
Either more people or at least louder people are doing this more and more. This is a problematic strategy for the same reasons a rollin
Re: (Score:2)
npm does not require you to install packages from the registry and your application's package.json dependencies do not either.
For production you can very easily have your own internal git server hosting your packages and dependencies, at specific verified versions.
Or if you don't like git you could have an internal SSL/TLS server hosting tarballs of all of the packages/dependencies.
The npm registry makes sharing packages easy but nothing says you have to use code straight from that to production.
Hell, you d
Re: (Score:1)
When your only too is a javascript interpreter, every problem looks like the back of the CEO's head.
Re: (Score:3, Informative)
Re: (Score:3)
Re: (Score:2)
My primary gripe with Javascript is that it really shows it was a scripting language for light use to liven up browser content a little bit, and overused from there.
It's a serviceable language, obviously, but the same factors that have Perl tempting developers to make hard to maintain code are present in Javascript (a whole slew of syntaxes for the identical thing), though it's a bit more extreme in Javascript. Also a tendency for certain functionality to look almost like an accidental behavior (e.g. 'obje
Re:Why would anyone use JavaScript?! (Score:5, Interesting)
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.
Re: (Score:2)
The problem being:
A) It's of limited comfort if you have to support a lot of browsers, with uneven support. Less dysfunctional than it used to be, but for example a KeyboardEvent to this day won't have a 'key' attribute in most *new* Webkit/Blink browsers, despite it being around for years.
B) A lot of the syntax for new things have to settle for approaches that are compatible with existing syntax. For example, requesting strict is a bare string 'use strict' string just hanging out. Arrow expression synta
Re: (Score:2)
Re: (Score:2)
Oh, I personally have found 'this' to be quite useful as it works in a number of scenarios (in the original application of futzing about with the DOM, the value of this is highly relevant). It's just an interesting example of offering multiple behaviors in different contexts. If you use an arrow expression, then this is similar to the concept as found elsewhere. If you use bind(), then this is always whatever gets bound (which can be an entirely different thing altogether).
I still maintain that as a lang
Re: (Score:3)
Re: (Score:2)
I can sort of understand using JavaScript in the browser. After all, it's the only option.
With WebAssembly, soon it won't be the only option in the browser. You'll be able to use APL for browser programming (if you can find a good keyboard somewhere).
Re: (Score:2)
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.
Most people don't consider PHP to be a better option.
Re: (Score:2)
Most people don't consider PHP to be a better option.
One could name perl or python... but then, compared to node.js and PHP, assembler and brainfuck are better choices.
Re: (Score:2)
One could name perl or python...
I'm using a Python-based static website generator for my website. No more MySQL or PHP attacks from hackers in Russia and Asia. Being able to load web pages in three seconds is also a nice bonus.
Re: (Score:1)
Good thing leftpad broke it, then! (Score:3)
Petulant developers save the internets!
Javascript and security? (Score:5, Insightful)
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? (Score:4, Insightful)
wget -O- https://example.org/install.sh [example.org] | 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... [heroku.com]
https://docs.docker.com/linux/... [docker.com]
https://nodejs.org/en/download... [nodejs.org]
Re: (Score:2, Insightful)
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 ==
Re: (Score:2)
Wait... there are people who run PHP code, on a server, as root? Untrusted PHP code they don't control to boot? Uhhh, wow.
Wait... there are people who run Python code, on a server, as root? Untrusted Python code they don't control to boot? Uhhh, wow.
FTFY...
It isn't about the language, it's about package management. Singling out Javascript makes you look like an idiot because yo
I am becoming wary of npm (Score:1)
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.
The issue with dep managers and version wildcards (Score:2, Insightful)
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).
Re: (Score:3)
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 priori
Why the Javascript hate here? (Score:1)
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
Re: (Score:2)
Rust never Sleeps (Score:2)
Where's the "Why don't they use Rust" guy?