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

321–330 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#321

Post by insanitybit »

pixl97 wrote: post #316
insanitybit wrote: post #135

Just some suggestions: 1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs. 2. Anywhere you have `npm install` or `npm test` or anything where code executes , that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and tes…

>install the latest version of zizmor. What if it gets compromised? More of a joke. But was funny after saying that new packages should be delayed.

lol yeah I thought of that as typing but figured I'd avoid the complexity. "latest version" means, give or take, whichever the latest one was that contained a bunch of new rules around supply chain stuff.

Re: Malicious npm packages detected across Red Hat Cloud Services

#322

Post by _pdp_ »

gred wrote: post #306
_pdp_ wrote: post #249

Earlier quoted context omitted.

Except that the JavaScript / NPM ecosystem is 6-7 times larger than Python and Java / Maven. https://chatgpt.com/share/6a1da751-0d88-832e-ace7-572bc786e0... Check the linked resource which has the actual data.

Thanks for the link. However, a 7x size differential does not fully explain a 100x security incident differential -- although I'm sure it's part of it. Some of the root causes are very hard to address (e.g. a very limited standard library which encourages dependency explosions), some are just hard (e.g. established cultural norms around version pinning and upgrades, well-established reliance on install scripts) and s…

The npm cli has bad defaults which you can turn off but they are there I presume for legacy reasons. The secure option is pnpm. The registry is fine.

Also on our comment about size differential ... it absolutely can.

If I jump from 2 meters hight it will be mildly uncomfortable. Jumping from 12 meters will result in severe injurious and possibly death. None of these things go linearly in real world conditions.

Re: Malicious npm packages detected across Red Hat Cloud Services

#323

Post by hedora »

winrid wrote: post #270
kylebebak wrote: post #207

Earlier quoted context omitted.

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

not if you have internal repos?

I think you can set it on internal repos, but then you need to allow-list internal code. People act like this is simple + solved, but it's not. It turns into 100K-1M's of LLM tokens on a semi-regular basis, or "just hire a build infra team for your side project" pretty quickly.

Re: Malicious npm packages detected across Red Hat Cloud Services

#324

Post by nicolewhite »

pavel_lishin wrote: post #294
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

From that repo:

> Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid.

My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing across installs -- it's the lockfile that accomplishes this.

Re: Malicious npm packages detected across Red Hat Cloud Services

#326

Post by hedora »

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…

There's a really bad implicit assumption in there: Microsoft's scanners have solved the halting problem, so they can tell if a package update will ever flip to malicious mode, or has an intentionally inserted security hole in it.

Of course, this also assumes that Microsoft's internal scanners are much better than the scanners available to the attackers, since any reasonable attacker is going to just run their obfuscated code through a scanner as part of their CI job. (And maybe even use the MS scanner as an oracle by submitting fragments to NPM to see which pieces of their exploit chain get flagged.)

Waiting until everyone else canaries is much stronger, but even that doesn't work on a targeted attack.

Re: Malicious npm packages detected across Red Hat Cloud Services

#327

Post by akio »

Sankozi wrote: post #280
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?

One malicious script that is run right after install vs one per each API entry point that might be called or not (transitive dependency).

[dead]

Re: Malicious npm packages detected across Red Hat Cloud Services

#328

Post by eranation »

nicolewhite wrote: post #324
pavel_lishin wrote: post #294

Earlier quoted context omitted.

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

From that repo: > Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid. My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing acr…

In most cases yes, but really depends on which package manager and what command, if you use npm ci, it uses the package-lock.json values, if you use npm install, it can use any levels of freedom in the package.json. So if you lock package.json you remove that degree of freedom. But sometimes you do want to be able to "recreate the lock file" since it does fix a CVE. Just with a lockdown, you'll get the legitimate patch vs an accidental malicious takeover.

Re: Malicious npm packages detected across Red Hat Cloud Services

#329

Post by tardedmeme »

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…

Every package manager, by design, allows arbitrary code execution after the update completes. It is the entire purpose of a package manager. There is no point installing code that does not run.

Re: Malicious npm packages detected across Red Hat Cloud Services

#330

Post by eranation »

Normal_gaussian wrote: post #319
eranation wrote: post #298

Earlier quoted context omitted.

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

> Changing your own car's oil is actually not that hard It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance. > Think of QR codes, people hardly use…

That group of people is the loosely affiliated people called "vibe coders". Even to get them to install depsguard is a challenge. I just ask them to point Claude to depsguard or cooldowns and follow the instructions (to save the tokens, of course Claude can figure it what needs to be done on its own)

The issue is that Claude Code also will be super happy to npm install axios / tanstack etc unless you explicitly tell it to add cooldowns.

Post reply on HN