Live data from Hacker News

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

safedep.io

11–20 of 329 posts

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

#11
post #10
post #7

Earlier quoted context omitted.

I also was at this point, and I decided to add cooldowns to every project.

Yeah, I agree, but then you are at the mercy of whatever vulnerability is found in the current version(s). It just feels like a lose-lose situation no matter what you do.

You can still update to new versions even if the new release is still in cooldown phase. You just have to be explicit that you want the new release.

pnpm audit —fix for example will whitelist releases in cooldown phase when theres a known security issue for a version you currently use.

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

#12
The situation is getting crazy ... personally I have already uninstalled node, python and all package managers from my machine and instead only use them in devcontainers / VMs.

But even if the dev community comes up with super hardened security, I fear in at least a year the models will be good enough in social engineering that we are still running a losing game.

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

#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) !

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

#14

The situation is getting crazy ... personally I have already uninstalled node, python and all package managers from my machine and instead only use them in devcontainers / VMs. But even if the dev community comes up with super hardened security, I fear in at least a year the models will be good enough in social engineering that we are still running a losing game.

how do containers solve the problem? if they are connected to the internet (and they are) you have got the same problem, if the credentials can be read by the container, at least to my understanding

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

#16
post #14

The situation is getting crazy ... personally I have already uninstalled node, python and all package managers from my machine and instead only use them in devcontainers / VMs. But even if the dev community comes up with super hardened security, I fear in at least a year the models will be good enough in social engineering that we are still running a losing game.

how do containers solve the problem? if they are connected to the internet (and they are) you have got the same problem, if the credentials can be read by the container, at least to my understanding

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

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

#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

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

#19
post #14

Earlier quoted context omitted.

how do containers solve the problem? if they are connected to the internet (and they are) you have got the same problem, if the credentials can be read by the container, at least to my understanding

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

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

#20

> 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) !

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

Post reply on HN