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

51–60 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#51

Post by Cthulhu_ »

gbuk2013 wrote: post #17

I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)

Nothing that couldn't be automated; in Go land this is (arguably) called vendoring (https://go.dev/ref/mod#vendoring). Good to offload or reduce dependencies on 3rd party dependency hosters, pull a dependency into your own code review tools, and to ensure reproducible builds long term.

Re: Malicious npm packages detected across Red Hat Cloud Services

#52

Post by ZiiS »

Tomte wrote: post #15
phoronixrly wrote: post #7

Earlier quoted context omitted.

What happens when everyone adopts this policy? You just change it to two weeks?

You rely on the security companies scanning the packages.

@exitb it is much more desirable for security scanning companies to compete to find issues in a timely manor. If npm blessed one as a gatekeeper to the whole system they would be between a rock and a hard place. Unable to priorities high impact packages over the long tail of packages no one uses without pissing people off. Unable to add experimental new detections that may be a little noisy at first due to the huge disruption it would cause. Be trivial to game as obscure packages could brute-force their way though then use the same hole on a mainstream package.

Re: Malicious npm packages detected across Red Hat Cloud Services

#54

Post by blm126 »

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.

I think the key right now is that these are semi-automated scanning processes. Right now, companies like step security selectively publish. So, in order for a hacking group to find out if their malware is detected or not, they have to burn access to a useful package.

None of this is to say I think Microsoft shouldn't be doing something as part of the release process on NPM. However, there is real value in giving more independent third parties a window to do things semi-manually.

Re: Malicious npm packages detected across Red Hat Cloud Services

#55

Post by phoronixrly »

blm126 wrote: post #33
phoronixrly wrote: post #7

Earlier quoted context omitted.

What happens when everyone adopts this policy? You just change it to two weeks?

The one week cooldown option is not relying on other users to be a canary for you. Its just giving automated scanners a chance to notice. This is the perfect example. I don't think step security found this by accident. They are actively monitoring NPM package releases at some level. There is something to be said that Microsoft should be scanning packages pre-release. They aren't, though, so for right now there is a t…

Thank you for the thorough response. I got the following from yours and other responses:

* The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread.

* This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user canaries as well.

* Maybe NPM should run scanners before distributing malware?

* If the ecosystem by any chance adopts a week-long quarantine period, you'd be safer if you applied a longer quarantine period.

Re: Malicious npm packages detected across Red Hat Cloud Services

#56

Post by bakugo »

phoronixrly wrote: post #7
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...

What happens when everyone adopts this policy? You just change it to two weeks?

This will never happen unless it's made the default. Most people will always stick with the defaults.

Re: Malicious npm packages detected across Red Hat Cloud Services

#57

Post by Ukv »

phoronixrly wrote: post #7
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...

What happens when everyone adopts this policy? You just change it to two weeks?

Security scans and authors realizing an unauthorized version was pushed will generally happen regardless of whether regular users updated. Even for compromises that are found by users updating, it'd generally be better to reduce the number of people affected with a slow roll-out rather than everyone jumping on at once.

Re: Malicious npm packages detected across Red Hat Cloud Services

#58

Post by jauntywundrkind »

CBLT wrote: post #29
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.

Eh, it's worse than that. The GP comment is repeating a joke derived from an Onion headline about gun control. Where the very poignant message is about political will to make change. However, the npm ecosystem is very much willing and has already made several changes. If we're going to engage in discussion instead of meme-posting, the GP should have (imo) included real commentary _in addition to_ the meme they really…

They didn't back up their meme with real commentary because they have no real commentary to stand on:

They're spreading cheap disdain & scorn for npm ("only package manager" framing). But most other package management systems have similar abilities to run pretty un-sandboxed code.

TrapDoor has hit python, rust, and js repos. https://socket.dev/blog/trapdoor-crypto-stealer-npm-pypi-cra...

Re: Malicious npm packages detected across Red Hat Cloud Services

#60

Post by kalcode »

Defletter wrote: post #37
kalcode wrote: post #27

Earlier quoted context omitted.

People make this joke often. It's package managers and how loose we are with installing them, not NPM. Cargo,PyPi,Nuget,PHP has had these recent too. It's not just only NPM. It's frequently repeated here just cause of the average bias against Node. But this problem isn't isolated to NPM.

The problem is compounded with NPM though thanks to lifecycle scripts: yes, any and all package managers create a risk of supply-chain attack, but NPM makes it dangerous to merely open a project up in an IDE.

That's a good point. For me it's getting people to realize they need to take up practice that help minimize these things. It's kinda us and them problem.

We need to ensure we don't just blindly install the latest, patch every CVE by just bumping everything to the latest even if the vulnerability has nothing to do with their system or use of said library.

We should have rules that we install the latest that's older than three days.

We should be running "npm audit" and other stuff like Trivy.

The three day rule alone could save most people.

Post reply on HN