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

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

541–550 of 796 posts

Re: NPM debug and chalk packages compromised

#541

Post by herpdyderp »

hnquestion10987 wrote: post #242

I'm a little confused after reading everything. I have an Expo app and if I run `npm audit`, I get the notification about `simple-swizzle`. The GitHub page ( https://github.com/advisories/GHSA-hfm8-9jrf-7g9w ) says to treat the computer as compromised. What does this mean? Do I have to do a full reset to be sure? Should I avoid running the app until the version is updated?

The advisories on GitHub were/are weird for several reasons:

1. The version matching was wrong (now fixed).

2. The warning message is (still) exaggerated, imo, though I understand why they’d pass the liability downstream by doing so.

Re: NPM debug and chalk packages compromised

#542

Post by 0xbadcafebee »

TheJoeMan wrote: post #527
0xbadcafebee wrote: post #278

Here we are again. 12 days ago ( https://news.ycombinator.com/item?id=45039764 ) I commented how a similar compromise of Nx was totally preventable. Again, this is not the failure of a single person. This is a failure of the software industry . Supply chain attacks have gigantic impacts. Yet these are all solved problems. Somebody has to just implement the standard security measures that prevents these compromises. W…

For a package with thousands of downloads a week, does the publishing pace need to be so fast? New version could be uploaded to NPM, then perhaps a notification email to the maintainer saying it will go live on XX date and click here to cancel?

A standard release process for Linux distro packages is 1) submitting a new revision, 2) having it approved by a repository maintainer, 3) it cooks a while in unstable, 4) then in testing, and finally 5) is released as stable. So there's an approval process, a testing phase, and finally a release. And since it's impossible for people to upload a brand new package into a package repository without this process, typosquatting never happens.

Sadly, programming language package managers have normalized the idea that everyone who uses the package manager should be exposed to every random package and release from random strangers with no moderation. This would be unthinkable for a Linux distribution. (You can of course add 3rd-party Linux package repositories, unstable release branches, etc, which should enforce the same type of rules, but they don't have to)

Linux distros are still vulnerable to supply chain attacks though. It's very rare but it has happened. So regardless of the release process, you need all the other mitigations to secure the supply chain. And once they're set up it's all pretty automatic and easy (I use them all day at work).

Re: NPM debug and chalk packages compromised

#543

Post by gslepak »

egorfine wrote: post #452
gslepak wrote: post #254

Tips to protect yourself from supply-chain attacks in the JavaScript ecosystem: - Don't update dependencies unless necessary - Don't use `npm` to install NPM packages, use Deno with appropriate sandboxing flags - Sign up for https://socket.dev and/or https://www.aikido.dev - Work inside a VM

> Don't update dependencies unless necessary And get yourself drowning in insurmountable technical debt in about two months. JS ecosystems moves at an extremely fast pace and if you don't upgrade packages (semi) daily you might inflict a lot of pain on you once a certain count of packages start to contain incompatible version dependencies. It sucks a lot, I know.

> daily

Somehow we've survived without updating dependencies for probably at least a year.

Re: NPM debug and chalk packages compromised

#544

Post by acdha »

sneak wrote: post #472
winwang wrote: post #68

Earlier quoted context omitted.

Just want to agree with everyone who is thanking you for owning up (and so quickly). Got phished once while drunk in college (a long time ago), could have been anyone. NPM being slowish to get back to you is a bit surprising, though. Seems like that would only make attacks more lucrative.

Can happen to anyone… who doesn’t use password manager autofill and unphishable 2FA like passkeys. Most people who get phished aren’t using password managers, or they would notice that the autofill doesn’t work because the domain is wrong. Additionally, TOTP 2FA (numeric codes) are phishable; stop using them when U2F/WebAuthn/passkeys are available. I have never been phished because I follow best practices. Most peop…

I also use WebAuthn where possible but wouldn’t be so cocky. The most likely reason why we haven’t been phished because we haven’t been targeted by a sophisticated attacker.

One side note: most systems make it hard to completely rely on WebAuthn. As long as other options are available, you are likely vulnerable to an attack. It’s often easier than it should be to get a vendor to reset MFA, even for security companies.

Re: NPM debug and chalk packages compromised

#545

Post by typpilol »

DDerTyp wrote: post #277
josefbud wrote: post #263

Earlier quoted context omitted.

I'm a little confused on one of the excerpts from your article. > Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3 As far as I've always understood, the lockfile always specifies one single, locked version for each dependency, and even provides the URL to the tarball of that version. You can define "x version or newer" in the package.json file, but if it upda…

You’re right and the excerpt you quoted was poorly worded and confusing. A lockfile is designed to do exactly what you said. The package.json locked the file to ^1.3.2. If a newer version exists online that still satisfies the range in package.json (like 1.3.3 for ^1.3.2), npm install will often fetch that newer version and update your package-lock.json file automatically. That’s how I understand it / that’s my curre…

You're correct

Re: NPM debug and chalk packages compromised

#546

Post by Goofy_Coyote »

junon wrote: post #9

Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…

Absolutely best response here.

Folks from multi-billion dollar companies with multimillion dollar packages should learn a few things from this response.

Re: NPM debug and chalk packages compromised

#548

Post by kesor »

dsff3f3f3f wrote: post #155
skydhash wrote: post #72

Earlier quoted context omitted.

I wouldn’t even use chalk. Altering terminal output is easy. But it should be used sparingly.

You're right. I only looked at the source for debug and ansi-styles. After looking at chalk it's insanity to add that as a dependency as well.

And yet it has 300M weekly downloads. I am fairly sure that most of these are not because it is a direct dependency of people's projects, but rather it is a dependency of a dependency of a dependency.

Re: NPM debug and chalk packages compromised

#549

Post by marcus_holmes »

dabockster wrote: post #500
fn-mote wrote: post #466

Earlier quoted context omitted.

Nah… Everybody knows npm is a gaping security issue waiting to happen. Repeatedly. It’s convenient, so it’s popular. Many people also don’t vendor their own dependencies, which would slow down the spread at the price of not being instantly up to date.

> Many people also don’t vendor their own dependencies, which would slow down the spread at the price of not being instantly up to date. npm sold it really hard that you could rely on them and not have to vendor dependencies yourself. If I suggested that a decade ago in Seattle, I would have gotten booed out of the room.

I have repeatedly been met with derision when pointing out what a gaping security nightmare the whole Open Source system is, especially npm and its ilk.

Yet here we are. And this is going to get massively worse, not better.

Re: NPM debug and chalk packages compromised

#550

Post by skydhash »

crabmusket wrote: post #535
skydhash wrote: post #468

Earlier quoted context omitted.

> what other language needs to distribute to an unknown runtime environment over the network? What is this unknown runtime environment? Even during the browser war, there was just an handful of browsers. And IE was the only major outlier. Checking the existence of features and polyfilling is not that complicated. And most time, the browser is already downloading lot of images and other resources. Arguing about bundle…

> Checking the existence of features and polyfilling is not that complicated. Judging by what we see in the world, most developers don't agree with you. And neither do I. A handful of browsers, multiplied by many versions per browser in the wild (before evergreen browsers like Chrome became widespread, but even today with e.g. Safari, or enterprise users), multiplied by a sprawling API surface (dare I say it, a stand…

> Judging by what we see in the world, most developers don't agree with you. And neither do I.

From my POV, most developers just test on the most popular browser (and the latest version of that) without checking if the API is standard or its changelog. Or they do dev on the most powerful laptop while the rest of the world is still on 8gb, FHD screen with integrated gpu.

Post reply on HN