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

221–230 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#221

Post by PunchyHamster »

saturn_vk wrote: post #170
matheusmoreira wrote: post #144

Earlier quoted context omitted.

> allows all packages to run package supplied arbitrary code as the logged-in user after an update completes As opposed to the completely untrusted package supplied arbitrary code that the logged in user executes when they actually use the package immediately after installing it?

The package might not ever be executed on the user's machine. Depending on your setup, it might only be ran on a server, where the data that can be exfiltrated is completely different.

Why you are downloading code if you're not even using it to run tests ?

And if you run tests in CI/CD, or in a container, why you are downloading code locally ? Only thing that comes to mind is code completion but surely most people at least run unit tests locally before pushing the code out ?

Re: Malicious npm packages detected across Red Hat Cloud Services

#222

Post by krautsauer »

nailer wrote: post #102
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_...

I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong. So, explicitly: - pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer (limited) - Maven ...all allow scripts. We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager. npm shouldn't…

Are scripts even necessary? I don't think e.g. mvn has any form of scripts¹, but if the dependency is compromised, you're likely to execute whatever compromised code is in there the next time you do mvn verify (or whatever). Slightly less wormable maybe, running tests or at least checking whether your thing still runs after upgrading package versions is really common, no?

¹ Annotation processors are a thing and somewhat similar to rust macros in function, but you need to set those up manually for each dependency, iirc.

Re: Malicious npm packages detected across Red Hat Cloud Services

#223

Post by philipwhiuk »

kalcode wrote: post #27
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_...

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.

In short, the problem is `npm` not NPM.

Re: Malicious npm packages detected across Red Hat Cloud Services

#224

Post by PunchyHamster »

rixed wrote: post #204
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…

One hour ago, while looking casually at a package.json, I saw this and was horrified: rm -rf pkg/snippets & rmdir pkg\\snippets /s /q & wasm-pack build --target bundler && node prepare-web.js Looked like a strange mix of unix shell and msdos batch that would, on my box, try to rmdir "/s" and "/q". I asked Claude about this, and he replied something like "Yes that's a standard and clever hack to delete a directory tha…

> Poor Claude has been trained on so much awful human code that it required several prompts for it to admit that there was indeed a problem.

Claude probably birthed this abomination in the first place

Re: Malicious npm packages detected across Red Hat Cloud Services

#225

Post by mbreese »

paulddraper wrote: post #203
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 is the volume of dependencies. Most modern JavaScript, Python, Rust, Go, etc. projects have many dozens of transitive dependencies.

Let’s not ignore that dependencies are far more common in JS than any of those other languages. My Go or Python projects generally only include a handful of external packages. Node projects on the other hand…

Re: Malicious npm packages detected across Red Hat Cloud Services

#226

Post by cozzyd »

rixed wrote: post #204
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…

One hour ago, while looking casually at a package.json, I saw this and was horrified: rm -rf pkg/snippets & rmdir pkg\\snippets /s /q & wasm-pack build --target bundler && node prepare-web.js Looked like a strange mix of unix shell and msdos batch that would, on my box, try to rmdir "/s" and "/q". I asked Claude about this, and he replied something like "Yes that's a standard and clever hack to delete a directory tha…

I hope the "standard" part is as much of a hallucination as "clever" is

Re: Malicious npm packages detected across Red Hat Cloud Services

#227

Post by isityettime »

m4rtink wrote: post #143
nailer wrote: post #102

Earlier quoted context omitted.

I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong. So, explicitly: - pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer (limited) - Maven ...all allow scripts. We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager. npm shouldn't…

If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution. Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack. Definitely not bulletproof but still IMHO more robust than "Lets…

Yeah with RPM and dpkg you're trusting the distro, or maybe individual distro maintainers, depending on how you consider it. But there are norms in the distro about what those scripts are for and how to use them, and there's some social enforcement around that.

The real issue for hooks in packaging formats like those is when you start adding third-party vendor repositories, e.g., Zoom, Google Chrome, Discord. None of the social enforcement mechanisms are there and the companies behind the products I just mentioned all have histories of abusing them.

That's why it's generally better to use Flatpak for things like that if your distro itself doesn't include them.

Re: Malicious npm packages detected across Red Hat Cloud Services

#228

Post by cozzyd »

m4rtink wrote: post #143
nailer wrote: post #102

Earlier quoted context omitted.

I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong. So, explicitly: - pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer (limited) - Maven ...all allow scripts. We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager. npm shouldn't…

If DNF/RPM is used there will often be a separate distro maintainer that should ideally review any changes coming from the upstream before pulling them into the distribution. Also not all maintainers always pull in the latest upstream changes, only rebasing to new stable release or when the new features or fixes are actually needed for the distro stack. Definitely not bulletproof but still IMHO more robust than "Lets…

Yes and typically updates take a while to be deployed...

Re: Malicious npm packages detected across Red Hat Cloud Services

#229

Post by 0xbadcafebee »

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

The package event-stream was compromised and went unnoticed for 60 days: https://medium.com/intrinsic-blog/compromised-npm-package-ev...

The package axios was compromised, and hijacked the author's credentials, so every attempt at a fix was unfixed. https://www.trendmicro.com/en_us/research/26/c/axios-npm-pac...

The xz utility was backdoored for 2 months: https://gigazine.net/gsc_news/en/20240403-timeline-of-xz-ope...

A student researcher took over Python ctx and PHPass package maintainership, pushing out malicious changes, and that took over 7 days to be detected and fixed: https://infosecwriteups.com/how-i-hacked-ctx-and-phpass-modu...

Kaspersky found multiple PyPI packages that had been exploited for more than a year: https://www.kaspersky.com/about/press-releases/kaspersky-unc...

"LoftyLife" packages were exploited for several months: https://securelist.com/lofylife-malicious-npm-packages/10701...

Now that the attack window has changed to 7 days, all new exploits like these will come with time bombs to not trigger until 8 days.

Re: Malicious npm packages detected across Red Hat Cloud Services

#230

Post by wang_li »

nailer wrote: post #102
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_...

I've deleted and am rewriting this, to be more explicit, because HN downmodded the first comment to hell but I know I'm right and the crowd is wrong. So, explicitly: - pip - Cargo - apt/dpkg - dnf/yum - Homebrew - RubyGems - Composer (limited) - Maven ...all allow scripts. We understand the reference, it's just not correct: most package managers allow scripts, npm is the most successful package manager. npm shouldn't…

It's not the package manager, it's the repo and the cryptographic signatures that are trusted by the package manager and the users who choose to point their pacakge managers at those repos. The fundamental problem here is that people's risk assessment is treating a user named devioustiger12345 as having the same situation and story as Microsoft/Apple/Red Hat.
Post reply on HN