Live data from Hacker News

Malicious npm packages detected across Red Hat Cloud Services

github.com

81–90 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#81

Earlier quoted context omitted.

And all of them "thought" of security as an after-after-after-after-after-thought.

Most of these are now building upon techniques that have already been exploited since past 1 years. This attack used 4 of those techniques. 1. Lifecycle Hook Execution 2. CI/CD Identity Plane Attacks 3. Maintainer Account Takeover and Malicious Publish 4. Self-Replicating npm Worms https://npm-supply-chain-attack-techniques.pagey.site/

Regardless of what these attacks exploit, see elsewhere a larping comment of mine: the solution exists, the implementation already mitigated numerous such and other exploits (it's nice to read "nix is not affected" on discourse or over matrix chat), it predates Docker by a decade, and is older than Ubuntu and Fedora (to give the perspective), yet people prefer to remain ignorant.

Re: Malicious npm packages detected across Red Hat Cloud Services

#83
post #5

Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

There is something to be said about the need to keep all the packages as the latest and the greatest at all times. Every minor version update doesn’t need to be immediately applied. And maybe high and critical vulnerabilities don’t need to be a minor version upgrade.

"maybe high and critical vulnerabilities don’t need to be a minor version upgrade"

huh? what do you suggest instead?

Re: Malicious npm packages detected across Red Hat Cloud Services

#85

Earlier quoted context omitted.

Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…

> they've taken no action. Not running lifecycle scripts by default is eventually going to be the default behavior. Late is worse (edit: I meant better) than not at all. https://github.com/npm/rfcs/pull/868

Wait how is being late worse than not doing it at all? Is it true for mortgage payments and apologies?

Re: Malicious npm packages detected across Red Hat Cloud Services

#86
post #72

Earlier quoted context omitted.

Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…

Mosts packages manager, allow that. pnpm can still be exposed, afterall the worm simply have to wait you run tests locally.

I suppose.

But that's a "Perfect is the enemy of good"-like argument. Wherein: Why even reduce an easy to exploit attack surface when there could be holes elsewhere?! Because, you know, it makes things much more secure even if imperfect.

Plus, to me, it is a culture issue. npm just doesn't take security seriously, so we don't see these improvements, and if there was additional test hardening later, I don't expect we'd see them in npm either. Since, they just don't care.

Re: Malicious npm packages detected across Red Hat Cloud Services

#87
post #25

Earlier quoted context omitted.

All programming language package managers are vulnerable. They all have the exact same caveats as the Arch Linux User Repository. There are no trusted maintainers taking responsibility for things. Any random person can make an account and push packages.

While true, tarring Arch here is a little unfair. AUR isn't enabled by default. It can't even be used via the same package front end, and in fact the "official" usage model requires that you clone the source yourself. Indeed, AUR is bad as a software distribution mechanism (really it's best understood as a proving ground for baby packages before they get real maintainers and distro blessing), but it's less bad than N…

I'm not tarring Arch, I was praising it. I made sure to explicitly spell out the "User Repository". Arch is the one that does it right.

Re: Malicious npm packages detected across Red Hat Cloud Services

#89
post #71
post #3

'No Way to Prevent This,' Says Only package manager Where This Regularly Happens Edit: some people don't understand that it's a defence to https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

Please stop posting this on every single security incident thread with npm. It was funny once, it's just rehashing the same debate over and over.

On the other hand, if the same problem keeps happening, it's hard to argue that the problem isn't foundational to the design and that it should be called out until either the problem is fixed or the design abandoned.
Post reply on HN