Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

safedep.io

Post reply on HN
Print view View original

41–50 of 329 posts

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#41

Post by sevenzero »

AgentME wrote: post #39

Another supply chain attack found and blocked in a day. Everyone regularly using npm to install new packages should be using npm's min-release-age setting to avoid package versions that are newer than a few days old to avoid most attacks in practice like this. You can set it to two days with `npm config set min-release-age=2` for example. https://cooldowns.dev/ has info about equivalent settings in other dependency m…

Or just use dependencies from 6 years ago and never update them like most companies i ever worked for.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#43

Post by cyanydeez »

Maakuth wrote: post #26
jeswin wrote: post #20

Earlier quoted context omitted.

> Make sure you're running a rootless VM engine (e.g. podman instead of docker) ! Aren't most people running docker rootless (at least on Linux)? Does podman do more?

The docker CLI tool is normally executed with user privileges, but there's dockerd, a daemon running as root that actually does the container execution.

im not sure people understand the security vectors. a user with docker permissions effectively has root permissions.

often, docker in docker is used to manage docker orchestration. putinng a user in a docker and peoviding docker access is security through obscurity.

on the flip side, i see people blindly installing tools and skills not understanding they are pushing context and capabilities without any significant security features.

Imagine mythos is actually exceptional hacker. if you give it a well crafted malicious prompt, its going to even more insecure.

the double edged sword is really fascinating to think about

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#44

Post by cyanydeez »

rubnogueira wrote: post #40

aube (npm/yarn/pnpm drop-in alternative) now has a "jailBuilds" flag that restricts access to network/filesystem access. https://aube.en.dev/package-manager/jailed-builds.html But this feels like a cat/mouse game.

dino was wired with security in mind, but you can see developers dont tend towards aecurity

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#45

Post by cyanydeez »

silon42 wrote: post #19
mentalgear wrote: post #16

Earlier quoted context omitted.

For credential stealing, that is true, but at least it would protect your local machine. But I just read these worms also try container escape ...

We need to prevent direct connections to internet for containers... once you have a proxy, predefined credentials (api keys) can maybe be added there (per container/target).

the model most people are talking about is in the cloud. for the harness to do useful work, it needs to talk to the cloud

the trouble is, we need protocols that are software determined that force AI interaxtions into limited scope but currently theyre all just bash adjacent and inherit your tools.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#46

Post by Tade0 »

wereHamster wrote: post #25
jonkoops wrote: post #17

Another day, another pre/postinstall script executed that could have easily have been prevented by any sane package manager. NPM really desperately needs an 'allowBuilds' style allowlist [1] and 'approve-builds' command [2]. 1. https://pnpm.io/settings#allowbuilds 2. https://pnpm.io/cli/approve-builds

After I upgraded pnpm to v11, I set all allowBuilds to false and have not observed any failures. Made me wonder why the packages even need build scripts. My guess is for obscure or old platforms, but for most users running on Linux or Darwin build scripts seem to be unnecessary.

> Made me wonder why the packages even need build scripts.

Historically it was to accommodate packages like the original SASS compiler:

https://sass-lang.com/ruby-sass/

Other times it was to avoid shipping binaries due to, erm, safety concerns. The package would include code in a different language, which in turn would compile into a binary library or executable.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#47

Post by cyanydeez »

abhisek wrote: post #34
somelamer567 wrote: post #28

In the fictional universe of William Gibson's Sprawl trilogy, it is legal and normal for defenders to go kinetic on cyberattackers. How long until it is simply easier for governments and big business in the countries victimised by these criminal groups, to find the path of least resistance and go after them personally?

Attackers are just having fun due to abysmal state of npm and some of the insecure design choices by GitHub and GitHub Actions. Every attack gives them credentials which in turn used to stage more attacks.

perfect capitalism writ technology

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#48

Post by mentalgear »

mentalgear wrote: post #13

> Docker Container Escape > The payload checks for the Docker socket and, if present, attempts container escape through three sequential methods: So even if you're running devcontainers / VMs, these worms are already trying to escape. Make sure you're running a rootless VM engine (e.g. podman instead of docker) !

You may run

> podman info --format '{{.Host.Security.Rootless}}'

to ensure podman is rootless in your config.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#49

Post by Havoc »

vsgherzi wrote: post #33
mentalgear wrote: post #13

> Docker Container Escape > The payload checks for the Docker socket and, if present, attempts container escape through three sequential methods: So even if you're running devcontainers / VMs, these worms are already trying to escape. Make sure you're running a rootless VM engine (e.g. podman instead of docker) !

I really wish we would’ve gotten something more like jails or zones. Or better yet put the containers in a jail or zone. Is there a comprehensive sandbox for Linux like the bsds have?

Unprivileged LXCs get pretty close. Less unified design wise but on some aspects better - kernel escape doesn’t land you on a 0 UID

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#50

Post by rubnogueira »

cyanydeez wrote: post #44
rubnogueira wrote: post #40

aube (npm/yarn/pnpm drop-in alternative) now has a "jailBuilds" flag that restricts access to network/filesystem access. https://aube.en.dev/package-manager/jailed-builds.html But this feels like a cat/mouse game.

dino was wired with security in mind, but you can see developers dont tend towards aecurity

Because there is a time and effort cost to swap over to another framework/runtime even if it brings benefits, and security is always considered "good for now" unfortunately.

That is what made Bun popular, and tools like uv/pip, oxlint/eslint, orbstack/docker desktop, and the list goes on. Drop-in replacements where we get 10x with little effort.

Post reply on HN