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

91–100 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#91

Post by chipdale »

junon wrote: post #71
jofzar wrote: 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.

Why should they stop? Maybe they want to rehash the issue that's not being adequately addressed. Maybe it's not supposed to be funny.

How do you propose we address this issue? Instead of policing what people say, are you interested in sharing your or someone else ideas?

Re: Malicious npm packages detected across Red Hat Cloud Services

#93

Post by TylerE »

ImPostingOnHN wrote: post #74
Someone1234 wrote: post #34

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…

Nearly every package manager I've ever used had post-install scripts. Most run as root, since that's what usually what the package manager runs as. It's not unreasonable: you're already installing software, which presents risks. If post-install scripts were not a thing, a payload could still run because you ran the software you installed. Or because the installer added it to auto-run. Or because the installer placed…

Nearly every package manager I've ever used had post-install scripts.

You're collapsing two different threat models. The risk isn't that code runs, it's WHEN it runs. This worm spreads because npm install runs arbitrary scripts as you, automatically, just from resolving the tree. You don't have to build it, run it, or even import it. Opening the project in an IDE is enough. apt/dnf scripts run on packages a maintainer signed and a distro gatekept. Not on whatever some rando pushed to a public scope 20 minutes ago that landed in your lockfile six levels deep. "They both technically execute code" is true and beside the point. One runs signed code from a trusted path, the other runs unsigned code from the default automated path. That's the whole ballgame.

Re: Malicious npm packages detected across Red Hat Cloud Services

#94

Post by Kuinox »

Someone1234 wrote: post #86
Kuinox wrote: post #72

Earlier quoted context omitted.

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'…

The biggest problem is not software but culture, not at npm, but in the js ecosystem. The js ecosystem is simply a juicy targets, the attack surface is enormous. The attacker can make their attack more sophisticated, there will always be a maintainer that can seed the worm spread.

Meanwhile in the nuget ecosystem is way smaller and have way less mainteners involved for a single given dependency.

Re: Malicious npm packages detected across Red Hat Cloud Services

#95

Post by Bilal_io »

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. :)

The problem would be the dependencies of your dependencies, and keep going many levels.

Re: Malicious npm packages detected across Red Hat Cloud Services

#96

Post by jdiff »

ImPostingOnHN wrote: post #74
Someone1234 wrote: post #34

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…

Nearly every package manager I've ever used had post-install scripts. Most run as root, since that's what usually what the package manager runs as. It's not unreasonable: you're already installing software, which presents risks. If post-install scripts were not a thing, a payload could still run because you ran the software you installed. Or because the installer added it to auto-run. Or because the installer placed…

Most package managers with postinstall scripts are also heavily curated and have reputation systems. As you say, they run as root, so the high trust requirement is definitely warranted. Anyone can upload an npm package.

Re: Malicious npm packages detected across Red Hat Cloud Services

#97

Post by junon »

chipdale wrote: post #91
junon wrote: post #71

Earlier quoted context omitted.

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.

Why should they stop? Maybe they want to rehash the issue that's not being adequately addressed. Maybe it's not supposed to be funny. How do you propose we address this issue? Instead of policing what people say, are you interested in sharing your or someone else ideas?

It's not that there isn't a conversation to be had. It's that it's a low-effort, karma farming, reddit-tier comment that always invites emotional/reactionary responses, typically the same ones as before, that usually shoots to the top of the comments section and drowns out any relevant or interesting (see: curious, as per HN guidelines) discussion.

Re: Malicious npm packages detected across Red Hat Cloud Services

#99

Post by matheusmoreira »

gbear605 wrote: post #66
CBLT wrote: post #29

Earlier quoted context omitted.

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…

One easy change would be that before any package can be published, it has to wait a minimum of two weeks in a state where it can be reviewed but it can't be installed without jumping through several hoops with big warning signs, things like "INSTALL_INTENTIONALLY_DANGEROUS_PACKAGES_THAT_WILL_BREAK_MY_COMPUTER=1", selecting yes in a dialogue that asks if they want to install software that likely has viruses, and point…

> where it can be reviewed

> Critically, there must be time for someone to review

By who? No one at npm is reviewing anything. "Someone" is doing a lot of work here.

Linux distributions have trusted maintainers who are responsible for their packages. People who cared enough to figure out PGP and set up an actual web of trust. That's where the verification happens. All these programming language package managers have nothing of the sort. PyPI, Rubygems, crates, npm, it doesn't matter. I can just make an account and push whatever I want.

These package managers are like this because that's what developers actually want. They don't want to deal with Linux distribution maintainers in order to get their software into the official repositories. They want to just run $packager push and have it out there with zero friction.

Re: Malicious npm packages detected across Red Hat Cloud Services

#100

Post by insanitybit »

Someone1234 wrote: post #34
jofzar wrote: 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_...

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…

> That's an INSANE default.

It's also the standard, and by far it's the contrast to not allow this. pnpm has a massive advantage of being the non-standard package manager, npm does not have that - what do you suggest that npm does?

Post reply on HN