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

Malicious npm packages detected across Red Hat Cloud Services

github.com

Post reply on HN
Print view View original

391–400 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#391

Post by michaelt »

mnahkies wrote: post #352

In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintai…

> - MFA for publishing: https://docs.npmjs.com/requiring-2fa-for-package-publishing-...

> - trusted publishers, available for about a year: https://docs.npmjs.com/trusted-publishers

According to [1] "All affected packages were published via GitHub Actions OIDC from the RedHatInsights/javascript-clients repository, indicating the upstream CI/CD pipeline itself was compromised."

So the malicious package would have gotten the happy little green star, with users assured it was "Built and signed with provenance."

[1] https://lwn.net/Articles/1075742/

Re: Malicious npm packages detected across Red Hat Cloud Services

#392

Post by za3faran »

mnahkies wrote: post #352

In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintai…

Why doesn't Java seem to have anything close to this issue? Isn't it a solved problem?

Re: Malicious npm packages detected across Red Hat Cloud Services

#393

Post by gus_ »

saturn_vk wrote: post #186
matheusmoreira wrote: post #10

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.

IIRC, go cannot run arbitrary code at build time, so that should not make it vulnerable

https://www.reddit.com/r/neovim/comments/1j45stl/someone_wro...

Re: Malicious npm packages detected across Red Hat Cloud Services

#394

Post by saghm »

ZiiS wrote: post #345
make3 wrote: post #340

Earlier quoted context omitted.

theoretical question, do cooldowns still work if everyone has them?

Less well maybe but yes. Security researchers still proactively test them, and the maintainer has a much better chance of catching it themselves.

I'd argue that we don't actually know if this is the case or not because we haven't yet gotten to that point. How do we know that security researchers won't just move to testing things later as well?

Re: Malicious npm packages detected across Red Hat Cloud Services

#395

Post by [deleted] »

eranation wrote: post #370
doctorpangloss wrote: post #333

Earlier quoted context omitted.

what is the difference between these two things from the point of view of how much work you have to do? - checking every update of every dependency to see if is a relevant urgent security update - checking every update of every dependency to see if it turns out to be a supply chain exploit am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly e…

It's a tradeoff, and I don't have hard data, but the cases where a reachable, exploitable, zero day CVE that requires an urgent immediate patch (usually unintentional vulnerability) vs complete dev machine / CI/CD takeover of a supply chain attack (malicious intent) - show that a 7 day cooldown (or even 24 hours) would be the safe choice. I should probably consider doing this research, didn't get to it yet.

[deleted]

Re: Malicious npm packages detected across Red Hat Cloud Services

#396

Post by saghm »

AgentME wrote: post #383
ajross wrote: post #357

Earlier quoted context omitted.

IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate…

But there is a second level of people reviewing packages on npm. They're the ones that report issues like the github issue this HN thread is linked to, and they very frequently get malicious npm packages taken down within a day of publishing. The big issue is just that not everyone is using a cooldown to avoid packages less than a day old and so people who install new packages at unlucky times don't get the benefit o…

I don't understand why you're confident that those Github issues won't just end up coming later if literally everyone adds this cooldown

Re: Malicious npm packages detected across Red Hat Cloud Services

#397

Post by doctorpangloss »

AshamedBadger56 wrote: post #372
doctorpangloss wrote: post #333

Earlier quoted context omitted.

what is the difference between these two things from the point of view of how much work you have to do? - checking every update of every dependency to see if is a relevant urgent security update - checking every update of every dependency to see if it turns out to be a supply chain exploit am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly e…

I believe the point is that if you delay patches until X days after release, usually someone will catch it and the maintainer or the package manager will pull the infected release. Thus, by you doing nothing and waiting X days, you protect yourself by never even getting the bad release. Then on the flip side, you just keep up with urgent security updates and push bad ones through faster after vetting them.

[dead]

Re: Malicious npm packages detected across Red Hat Cloud Services

#398

Post by cluckindan »

chillax wrote: post #346
make3 wrote: post #340

Earlier quoted context omitted.

theoretical question, do cooldowns still work if everyone has them?

Companies such as socket and safedep will still scan new packages and alert on malware (if they are able to detect it) so the packages are taken down before they pass your cool down

It’s kind of insane this doesn’t happen in the publish pipeline by default.

Re: Malicious npm packages detected across Red Hat Cloud Services

#399

Post by bram98 »

kylebebak wrote: post #207
dmix wrote: 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...

npm supports this now as well, with e.g. `min-release-age=7` in `.npmrc`

Why not the other way around, I man by default and can be changed.

Re: Malicious npm packages detected across Red Hat Cloud Services

#400

Post by saghm »

exitb wrote: post #21
Tomte wrote: post #15

Earlier quoted context omitted.

You rely on the security companies scanning the packages.

Well, if that actually works, it should be part of the release process, before the packages get placed onto the regular channels.

Yeah, this is the part that I don't get. If the solution is "security testing should come before people install it", why is the big push to have people intentionally add this artificial delay to install later rather than moving the security testing earlier to before the release? If you want to make people not drive on the road until the pavement dries, you don't try to convince everyone to push back their workday by an hour; you just lay the asphalt an hour earlier.
Post reply on HN