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

291–300 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#291

Post by m4rtink »

Romario77 wrote: post #167
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…

I think another thing that affects security is that in javascript culture people often tie to the latest version instead of concrete version. This makes it so an update to a popular library can compromise a huge number of packages that depend on it. In Java for example almost all packages specify a concrete version, even if someone compromises the latest the blast radius is usually pretty small.

Won't pinning a version lead to dependency hell, not to mention potentially using vulnerable versions if you don't a new version after it has some CVE fixes ?

Re: Malicious npm packages detected across Red Hat Cloud Services

#292

Post by MattSteelblade »

tremon wrote: post #264
rixed wrote: post #204

Earlier quoted context omitted.

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…

To meekly defend the indefensible here: it's not like rmdir on Linux (I won't speak for all Unixen) can cause loss of data, since it only removes empty directories.

In this case, the rm -rf before that does. The rmdir is the Windows command in this example and with /s /q, it will quietly delete everything.

Re: Malicious npm packages detected across Red Hat Cloud Services

#294

Post by pavel_lishin »

eranation wrote: post #234

Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…

A friend of mine has a github repo with references to how to set things up in sane and slightly more secure manner: https://github.com/jordanconway/package-manager-hardening

Re: Malicious npm packages detected across Red Hat Cloud Services

#295

Post by Someone1234 »

jmull wrote: post #271
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…

> That's an INSANE default. I agree that not running arbitrary installation scripts is the right default, but it's just an incremental improvement. The practical difference between code that runs at installation and code that runs when the package is executed is, very typically, a small amount of time. IMO, the hyperbole here hurts because it distracts from more effective efforts.

> IMO, the hyperbole here hurts because it distracts from more effective efforts.

For example?

Re: Malicious npm packages detected across Red Hat Cloud Services

#296

Post by halapro »

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…

npm is so bad at everything it's insane.

SIXTEEN YEARS of development and they can't even resolve a tree of dependencies in the correct manner unless you nuke the lockfile and node_modules.

Dependency resolution is literally the number one task and they fail at it. How can you expect them to be good at anything else? Absolute joke.

Re: Malicious npm packages detected across Red Hat Cloud Services

#297

Post by m4rtink »

tonymet wrote: post #262
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…

So does dpkg & rpm

That usually has a separate maintainer checking things, not updating automatically and often being the author of those packaging scripts, as they are often distro specific.

Re: Malicious npm packages detected across Red Hat Cloud Services

#298

Post by eranation »

Normal_gaussian wrote: post #284
eranation wrote: post #234

Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…

> If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. This feels like a very very small group of people; and people who really could do with opening the file and adding the line.

I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers. In any funnel, each step, no matter how easy, adds friction, remove the friction and you get bigger adoption.

So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)

Re: Malicious npm packages detected across Red Hat Cloud Services

#299

Post by bakkoting »

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…

They have taken action as of very recently. The latest version [1] of npm warns when there are install scripts and tells you they will be disabled by default in a future version, with a per-dependency opt in mechanism [2].

[1] https://github.com/npm/cli/releases/tag/v11.16.0

[2] https://github.com/npm/rfcs/pull/868

Re: Malicious npm packages detected across Red Hat Cloud Services

#300

Post by Zardoz84 »

krautsauer wrote: post #222
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…

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

ant-plugin and maven-assembly.

But pulling a maven dependency DON'T run anything. You must download the repository that contains the POM.XML and run mvn with any goal that triggers the lifecycle.

Maven 4 aims to separate distribution and build poms. Currently, we generate distribution pom.xml for distribution using flatten plugin.

Post reply on HN