Worried about occasional npm malware scares? It's more common than you may think

Malware gets spotted in GitHub's npm registry every few months, elevating concerns about the software supply chain until attention gets diverted and worries recede until the next fire drill. Incidents like the sudden removal of left-pad from npm in 2016 or the subversion of faker.js and colors.js last month get noticed, but …

[Sitaram Chamarty]

node/npm -- the new php

I'm one of those ultra cynics who consistently refused to let PHP on any internet facing server back when I was working on, and had a say in, such things.

Today I consider the node ecosystem to be just as bad in terms of the effort required (not just one time but on an ongoing basis) to keep it secure.

And I don't think I'm alone. I've often found comments on reddit and elsewhere, where, if someone posts a new tool in nodejs, will respond with "Uggh, node!" or "Node? No!" or similar. This is especially true for apps which don't really need to be written in JS (i.e. could have been written in any other language), although I cannot say if those comments are also driven by security concerns or just a general dislike of JS.

[Anonymous Coward]

Re: node/npm -- the new php

The problem with all of these things is the crappy developers (mis)using it.

Even in the old versions of PHP you could write good code, but you had to know what you were doing and had register_globals disabled, and that wasn't well explained.

Node in itself is not terrible but its lack of useful builtin and validated libraries is. Its other problem is it has a very very low barrier to entry as devs doing a little bit of browser JS is easy and nothing much to fret about. Its when they have grand plans about using that for an app that's when it all goes wrong the required skill level for that is crazily high.

As usual smarter languages, dumber developers, education is still king

[Pascal Monett]

"1,300 malicious JavaScript packages"

Everything JavaScript is malicious. Either it takes over your computer, or it destroys proper HTML rendering and linking.

NoScript is the only defense.

[captain veg]

Re: "1,300 malicious JavaScript packages"

It's just a programming language. Non-malicious people find it convenient for writing programs. Especially ones that need a GUI that fits the HTML model.

Your problem is, I think, that it's a programming language that can be delivered into your browser over HTTP. That doesn't happen spontaneously, of course, you do actually have to invite it in.

-A.

[Anonymous Coward]

Re: "1,300 malicious JavaScript packages"

The article strongly implies a NodeJS context, as that is the usual client for npm queries.

[sreynolds]

It's everywhere....

One good thing about the "kernel" is that at least a couple of humans get to look at the code before hand.

One bad thing about rust's crates is that it is just like NPM. You need to specify version x.y.z of a specific package and there is no source level guarantee.

In the olden days you used to know that small version numbers would not break things and the big version would mean you need to make changes. There is no reason to this versioning madness.

[502 bad gateway]

Surprised?

Seriously, no real surprise there, npm is the pebble dashed brick outhouse of the software development community. Some more than others feel the need to visit it on a semi-regular basis. Lord knows why.

[Rob Davis]

to store packages in git or not that is the question

Good article for awareness, thank you.

It resurrects the dilemma I have about what to store in git and wonder what other readers think: to store whole dependency packages in git or not.

If one stores everything in their project in git, including the dependency packages complete source code, the whole project and exact code is stored, which can provide assurance that where it is deployed, it will always be the same. And when any changes from a package update will be seen as git changes. So this can make it quicker to see changes. However, pull requests could be large, making it take longer to find changes to the project's own code by a developer, if the changes required dependency updates to be included in the same commit. I suppose it depends on how git commits are managed.

On the other hand, if one only stores the dependency list files i.e. the .json etc files and not the dependency code itself, then code reviews can be quicker and docus on changes to the project's own code, more time to focus on them, picking up more faults that might have been missed otherwise. But, by just including the package list in git, then the code in the packages won't be seen in the review if changed, which is where security issues can creep in.

This is consideration for other development platforms such as php and php composer, too.

What do you folks think?

I guess there might need to be more stewardship at npm source. I think microsoft have some involvement (ownership?) so their experience of malware and counteracting tools could be useful here.

[Anonymous Coward]

Re: to store packages in git or not that is the question

> to store whole dependency packages in git or not.

Not.

Storing package*.json achieves the same thing (absent a serious breach of security of either your package repository of choice or your git repository) and is both easier to manage and easier to spot changes.

For the rest, it's about a multipronged approach, e.g.:

* Minimise external dependencies. You don't need trivial packages or stuff you can do without, for instance a fancy logging library; console.log does the job just as well.

* For those external dependencies that you do need, consider which amongst them are critical ones. This means: you can't easily replace them with something else without major effort. Things like database client libraries fall in this category.

* Consider hosting your own mirror of those critical dependencies and pulling the packages not from the NPM repository (you should avoid NPM altogether if you can) but from your own. If your package does not require building, you can pull directly from Git.

* Companies such as GitLab offer a number of tools to maintain integrity and run automated security audits. Those are a good idea.

* Do inspect packages by hand occasionally. Even a quick egrep -R "https?://" might help uncover foul game.

* Monitor egress traffic and apply usual security precautions.

* Do so consistently. This is the sort of thing which you should document in a manner appropriate to your situation (quality management system record, blog post on your intranet / personal website, a README somewhere in your hard drive, … whatever works for you).

Good question btw!

[Blackjack]

Ehem

Take a look at this:

https://www.bitdefender.com/blog/hotforsecurity/node-package-manager-to-roll-out-forced-two-factor-authentication-for-all-projects-by-march-1/

[Anonymous Coward]

Re: Ehem

So... instead of uploading the rogue NPM directly, now I have to wait for a e-mail or code? Well, it's just too hard now.

2FA doesn't change anything about NPM, it's the NPM design itself that is the problem. To be semi-fair, in the beginning it was O.K., but after time passed it simply became a failed idea.

P.S. Read the last sentence of that link you posted, it's a good example of how little NPM users pay attention.

"... 2FA on all npm accounts should discourage man-in-the-middle attacks and offer a more secure platform for Java libraries"

Java... O.K.

[captain veg]

old skool

Most of the time that I've been creating software in return for money we either wrote it ourselves or paid for supported libraries that did tricky stuff.

Even for the tricky stuff, we first of all asked whether we could make it ourselves. Almost always the answer was yes, but we didn't have time.

Bought-in software is subject to contract. It's far from ideal, but at least it means that your company's bankruptcy lawyers might be able to salvage something. Free stuff on Github (or whatever), not so much.

I'm certainly not saying that everything on Github (or whatever) is worthless. I'm merely pointing out the obvious, that it comes with no guarantees.

Speaking for myself, if there were a particular problem domain for which I could not myself quickly code a solution I might consider checking out what's available in the public domain. But before I deployed it as part of any solution I would make damn sure that I had read all the source code and understood it. How else to prevent the ingress of, at minimum, buggy code, at maximum, malware?

-A.

[Anonymous Coward]

Re: old skool

That's the safe default mindset I think everyone should have but, there's no way to realistically read every line of code and be sure about everything in all things. There's plenty of Boost libraries that you'd have to spend 6 months to fully understand it all because, just because you understand the exact code in front of you, that doesn't mean you fully understand specs behind them to make sure that there's no flaws Boost's TCP library springs to my mind and while you maybe can learn all that, I'm simply "rolling with it" (especially since I'm solo).

[captain veg]

Re: old skool

> there's no way to realistically read every line of code and be sure about everything in all things

There is every way to do so. The question is whether that would be less onerous than writing the code yourself.

If you import free third party code into your program without knowing it inside and out, and it turns out to be malevolent, then you were reckless., If it turns out to be buggy, you were negligent. Better to write your own buggy code. At least then you'll have a chance of fixing it.

-A.

[Anonymous Coward]

Not huge

1300 out of 1.8M is about 0.7‰ (per mille)

Regardless, you do want to be very careful to avoid typos. Typosquatting, like with URLs back in the day, is a thing in the NPM world.

Always check what the proper package name is from the package's homepage (*not* from the NPM site!) and copy pasta the install command if possible.