Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

bleepingcomputer.com

Post reply on HN
Print view View original

591–600 of 1001 posts

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#591

Post by kristjansson »

maxclark wrote: post #113

What’s the fix here? Maintainers should be able to do whatever they want either their code But if they vandalize their modules that should be a lifetime ban from the registry It’s pretty obvious that node needs a better method for dealing with this by now

No. Maintainers should be able to publish whatever they want. Users should save whatever they want to consume locally for whatever specification of local (disk, mirror, whatever) works for them. Malicious actions will be rejected and punished by the marketplace. If GitHub et al want to be a value of local, i.e. controlled by the (community of) users then they can play that role, but no one should expect them to

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#592

Post by justinpombrio »

xg15 wrote: post #153
drawkbox wrote: post #97

Earlier quoted context omitted.

Dependencies are a major attack vector now. Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are entering a dependency attack massive war. Dependencies are a balance but also a sign of weakness of a system in the modern day. There at least needs to be delayed, dependency bot like analysis before you integrate. Even then, they just leave your systems open to…

How about using dependencies but pinning the version and only updating if you know what the update contains? I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.

> I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.

I think it follows from two things:

1. We use open source software for everything. This is also true of our dependencies, so we get hundreds or thousands of transitive dependencies. Many of which are presumably written by dogs, because (i) no one can tell if you're a dog on the internet, and (ii) OSS maintainers are so overworked they ask their dogs for help.

2. Languages and libraries are full of footguns, software is full of bugs and therefore vulnerabilities, and no one cares enough to go through the enormous effort to fix things. And this is true through the whole stack. So the only practical way to stay secure-ish is to reactively patch software as vulnerabilities are publicly discovered. And also defence in depth. (I would distinguish between the publicly known time that a vulnerability is discovered, and the first time it was discovered. You hope the two are the same but for many vulnerabilities, if a clever adversary found them first we'd never know.)

With these two things together, you have a ton of questionable dependencies, and you need to update them all the time for security reasons.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#593

Post by JimDabell »

notRobot wrote: post #21

Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…

> Packages are literally remote code exec vulns in the hands of package authors

Something mentioned in this article caught my eye:

> While searching for Marak’s libraries, I found this npm-test-access library. This library seems to be used for what the name describes: to test access to NPM. Marak seems like a very capable software engineer, and it’s unclear to me why he’d need a package like this. So, this make me personally doubt a little bit if Marak is really behind all of this, or if maybe his account got compromised, or if something else it at play.

— [0] https://jworks.io/the-faker-js-saga-continues/

If you wanted to take over other people’s NPM packages by pushing a compromised update to one of your own widely used packages, the first thing it would do is check to see if the victim had access to publish to NPM.

Marek, who has just started publishing malicious updates to his own widely used packages, has just created a package to check for access to NPM.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#594

Post by shaunpersad »

Dylan16807 wrote: post #509
dariusj18 wrote: post #447

Earlier quoted context omitted.

Except the license does say so

The license does say what? The license doesn't say any payment is necessary. The license doesn't say new versions will still work. The license doesn't say anything about complaints. If it's valid to complain about code breaking, it should also be valid to complain about lack of payment. These complaints are outside of the legal mandates of the license.

It isn't valid to complain about the code breaking. At least not with any consequences. Because the license explicitly says that the software is provided without warranty.

Likewise, the license explicitly says that the software is provided for free, therefore it isn't valid to complain about people not paying for it.

Nobody's on the side of the big corps here, but "why aren't you paying for this thing that I've given to everyone explicitly for free" seems nonsensical.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#595

Post by p2t2p »

pinum wrote: post #426
brundolf wrote: post #383

Earlier quoted context omitted.

Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev mac…

>You would discover a change like the one in the OP when you manually ran `npm update` on your dev machine, so it should get nowhere near production. Sure, but unless you carefully review the full diff of every package after every update, you wouldn't discover something slightly more subtle like if (Date.now() > 1648771200000) { require('child_process').exec("rm -rf ~") }

Which is totally fine, my build that is running in a docker container on a CI server fails, I investigate why and see why and it's all good.

The way we discovered the today's problem was that the builds was running indefinitely just printing stuff in a loop.

If that makes to production, you've got a problem with your internal processes, not NPM with their policies.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#596

Post by harlanji »

ehnto wrote: post #557
halostatue wrote: post #460

Earlier quoted context omitted.

This is, unfortunately, not true by default. I had a case where I did `yarn install` and there were updates installed. To make this work correctly, you need to do `yarn install --frozen-lock-file` or `npm ci`. It’s absolutely _insane_ that this is the case. Gemfile.lock, Cargo.lock, and every other lock file format that I have used in packaging does this correctly.

It used to be true. npm install used to do what npm ci does. It was super annoying to learn that the hard way. One of the core issues of NPM style package management is package bloat means you absolutely can't review all release notes for every module in your tree. So you just trust the top level packages, and pray they would mention something if their dependencies change how they themselves work. Practically I rarel…

Some orgs are much more in line with GP’s suggestion. Marketing sites may feel low risk and in my view the iteration speed required justifyies having a trusty stack with known good versions to start from. Personally my method of construction is very conservative and I thrive in B2B SaaS environments, where in Consumer front-end orgs I can be seen as a dinosaur at times. I love new and shiny things as much as the next dev, and enough incidents will hopefully create a more conservative culture of using free lunch-looking stuff more cautiously. Race to the bottom dynamics in a sense, lacking any regulation. The expectation is move fast and break things, I get that, because of the first to market/time is money bias/truth. Inexperienced devs won’t have the scars to push back if there are upstream changes to review while their boss expects the feature updates to be live ASAP. I imagine that with decades regulation will force certain processes—not that I want it more than the next dev who loves shiny stuff and delivering results fast/delighting my boss.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#597

Post by Osmose »

PragmaticPulp wrote: post #356
Osmose wrote: post #74

It's a bit wild that the sum total money spent on salaries for engineers handling potential problems stemming from this or defending against the possibility in the future could probably have covered paying the maintainer a living wage many times over.

The author didn’t write all of the code, though. The code has a long history (including in other languages) and many contributors. Why should this one developer collect payment but not everyone else who contributed it? Regardless, it’s ridiculous to give something away openly under a permissive license and then later get angry when people use it exactly as you license it.

> Why should this one developer collect payment but not everyone else who contributed it?

Exactly, no one said _only_ the lead maintainer should be compensated. _All_ of the labor, not just the labor that happens to have a day job that benefits from it, should be compensated. That includes non-coding labor like support or community management, too.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#598

Post by zepolen »

junon wrote: post #461
DangerousPie wrote: post #120

Earlier quoted context omitted.

> #AaronSwartz right...

Yeah, this was really annoying to see. Don't use him as a pillar to your malicious action.

You're new so I won't hold it against you. Aaron Swartz would have 100% approved of this.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#599

Post by xienze »

sverhagen wrote: post #448
xienze wrote: post #101

Earlier quoted context omitted.

A key difference with Maven projects is that you specify exact dependency versions instead of “always use latest” or some variant of that, as is pretty common in the Node world.

This is not necessarily true, there are version ranges: https://www.baeldung.com/maven-dependency-latest-version Admittedly, I don't think it has nearly as wide a usage as it has in the NPM world. Dependabot (I know I'm not the first to mention it, here, today) is probably more of a factor. Still , it strikes me that this sort of "attack" (or mishap) is exceedingly rare in the Java ecosystem, while it's pretty common…

I was not aware of that feature. To call it rare would be an understatement I think.

> while it's pretty common in the NPM world, and I don't immediately understand why that would be so.

I think it boils down to Node projects typically specifying dependencies in the form “any version >= X”, effectively “always use the latest.” Dependencies can therefore get bumped silently just by rebuilding, essentially. Whereas in the Java world updating dependencies is a deliberate process.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#600

Post by hsbauauvhabzb »

brundolf wrote: post #383
hsbauauvhabzb wrote: post #361

Earlier quoted context omitted.

Does updating it with junk take any longer?

Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev mac…

easy, throw a line of copywrite code in it so you can DMCA the plug-in later.
Post reply on HN