[dead]
Malicious npm packages detected across Red Hat Cloud Services
281–290 of 494 posts
Re: Malicious npm packages detected across Red Hat Cloud Services
#282Earlier quoted context omitted.
That's why we don't let the developers run system package manager install scripts as root. We do let them run npm inside containers, which is still more access than I'd like them to have.
Is this one of those places where it takes 6 to 12 weeks to get something new installed on your machine?
You mean directly on the machine? Not in a container? That would be a recklessly fast timeline. The configuration control board meets quarterly and it usually takes 4 or 5 meetings to clear a piece of software.
Re: Malicious npm packages detected across Red Hat Cloud Services
#283Earlier 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.
How many package managers allow executing arbitrary code as part of the installation process by default?
Almost all of them.
Re: Malicious npm packages detected across Red Hat Cloud Services
#284Hope 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.
Re: Malicious npm packages detected across Red Hat Cloud Services
#285Earlier quoted context omitted.
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 maintaine…
> apt/dnf scripts run on packages a maintainer signed and a distro gatekept Unfortunately apt/dnf isn't much better here because random tutorials online suggest people add random repositories where the creator of any repository effectively has root access to anyone machine that adds it as a remote.
It's the exact same problem when random tutorials (and official pages) recommend to do a curl "URL" | bash to install something. Every time that I see it, I look it suspicious.
Re: Malicious npm packages detected across Red Hat Cloud Services
#286Why blame on NPM? Would you blame GitLab if an opensource maintainer was hacked and as a result the repo contains malicious changes? All of these recent incidents is just developers doing stupid things ... like using their compromised devices for making production changes, which is basically a big red flag to begin with. In fact, the entire situation has been exacerbated by coding agents because now practically every…
no because I dont ship production software from gitlab, I use upstream maintained packages?
Re: Malicious npm packages detected across Red Hat Cloud Services
#287Earlier quoted context omitted.
Is this one of those places where it takes 6 to 12 weeks to get something new installed on your machine?
You mean directly on the machine? Not in a container? That would be a recklessly fast timeline. The configuration control board meets quarterly and it usually takes 4 or 5 meetings to clear a piece of software.
Interesting. How about in a container? What industry is this, just curious?
Re: Malicious npm packages detected across Red Hat Cloud Services
#288Earlier 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…
> 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?
You can't even install the package without running arbitrary code, that's quite different from most other package managers for languages.
Re: Malicious npm packages detected across Red Hat Cloud Services
#289Earlier quoted context omitted.
It’s on by default in yarn 4 too now, but pnpm was the first to market that default minimum gate. https://github.com/yarnpkg/berry/pull/7135
If this were a universal default, would the strategy defeat itself?
No.
Many places run analyzers on published code; many security users have reason to shorten the period. The default period becomes the period where white hats have a chance to detect it and stop it passing the threshold.
Re: Malicious npm packages detected across Red Hat Cloud Services
#290Earlier 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…
Yikes. I would never approve a PR with that in it.
Your agent might!