Live data from Hacker News

NPM flooded with malicious packages downloaded more than 86k times

arstechnica.com

231–240 of 308 posts

Re: NPM flooded with malicious packages downloaded more than 86k times

#231
post #185

Is the solution to this problem Golang style package management where you specify the git repo?

Any string can be typosquatted unfortunately.

Even worse, LLM hallucinations can be squatted to the same effect.

Re: NPM flooded with malicious packages downloaded more than 86k times

#232

Earlier quoted context omitted.

Don't do development on your local machine. Full stop. Just don't. Do development, all of it, inside VMs or containers, either local or remote. Use ephemeral credentials within said VMs, or use no credentials. For example, do all your git pulls on your laptop directly, or in a separate VM with a mounted volume that is then shared with the VM/containers where you are running dev tooling. This has the added benefit of…

That's not a realistic solution. Nobody is going to stop using their machine for development just to get some security gains, it's way too much of a pain to do that.

its not particularly painful to develop in a container. Maybe docker is a nuisance (although I know people do do develop within docker) but something like firejail or bubblewrap is pretty easy to use.

Re: NPM flooded with malicious packages downloaded more than 86k times

#233
post #211

Earlier quoted context omitted.

Just a heads up that Pypi isn't immune from the same attack, with "Pypi supply chain attack" into Google revealing a (much smaller) number of packages that turned out to be malware. Some were not misspellings either, with one being a legitimate package that got hacked via GitHub Actions and a malicious payload added to the otherwise legitimate package.

No language ecosystem is but NPM/Node still encourages this idea (borrowed elsewhere and interpreted poorly) that everything must be its own tiny package and that it's acceptable to author libraries consisting of thousands of transitive dependencies from potentially dubious sources. Just this week I saw one (unmaintained dependency of a popular package) which consisted of a list of a dozen SQL operators. Anywhere els…

It's a misconception that NPM or Node encourage this, because they don't. There are a few package authors that are doing it that way (some even paid by download count), but that's their opinion.

Recently there is a trend towards minimal-dependency packages and I would certainly recommend auditing every package for its dependencies before using it.

Re: NPM flooded with malicious packages downloaded more than 86k times

#234
post #76

Earlier quoted context omitted.

That seems a bit excessive to sandbox a command that really just downloads arbitrary code you are going to execute immediately afterwards anyways? Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run.

> Also I can recommend pnpm, it has stopped executing lifecycle scripts by default so you can whitelist which ones to run. Imagine you are in a 50-person team that maintains 10 JavaScript projects, which one is easier? - Switch all projects to `pnpm`? That means switching CI, and deployment processes as well - Change the way *you* run `npm` on your machine and let your colleagues know to do the same I find the second…

Yeah, id just take the time to convert the 10 projects rather than try to get 50 people to chnage their working habots, plus new staff coming in etc.

Switch your projects once, done for all.

Re: NPM flooded with malicious packages downloaded more than 86k times

#235
post #6
post #4

>When you run npm install, npm doesn't just download packages. It executes code. Specifically, it runs lifecycle scripts defined in package.json - preinstall, install, and postinstall hooks. What's the legitimate use case for a package install being allowed to run arbitrary commands on your computer? Quote is from the researchers report https://www.koi.ai/blog/phantomraven-npm-malware-hidden-in-i... edit: I was think…

Easy example that I know of: the Mediasoup project is a library written in C++ for streaming video over the internet. It is published as a Node package and offers a JS API. Upon installing, it would just download the appropriate C++ sources and compile them on the spot. The project maintainers wanted to write code, not manage precompiled builds, so that was the most logical way of installing it. Note that a while ago…

Running a C compiler on everyone's machines to avoid a bit of work is extremely dumb.

Re: NPM flooded with malicious packages downloaded more than 86k times

#236
post #179

Earlier quoted context omitted.

It's no different anywhere else. I just downloaded jj (rust), it installed 470+ packages When I downloaded wan2gp (python) it installed it install 211 packages.

Oh man you pick the one other language that followed the JavaScript model?! How about C, Java, Go, Lisp, C#, C++, D… and new ones like Odin that are explicitly against package managers for this very reason.

When you start writing with C, where do you get your stdio.h file? Do you write it yourself, or inspect it line by line every time or do you trust the installation package you just ran?

Re: NPM flooded with malicious packages downloaded more than 86k times

#237
post #220

Earlier quoted context omitted.

The entire Front end dev seems like trust me bro Wild West to me. All feels like endless layers of duct tape. Which I guess in a way it is given the evolution of browsers

it seems a lot worse with NPM for some reason, but the underlying weaknesses apply to language package managers in general too.

I think it is worse with npm because there are more people using it and more people know about it.

Lowering the barrier to entry is not paying off, for sure.

Re: NPM flooded with malicious packages downloaded more than 86k times

#238
post #124

Earlier quoted context omitted.

> alias npm=... I use sandbox-run: https://github.com/sandbox-utils/sandbox-run The above simple alias may work for node/npm, but it doesn't generalize to many other programs available on the local system, with resources that would need to be mounted into the container ...

Or use ‘chroot’. Or run it as a restricted owner with ‘chown’. Your grandparents solutions to these problems still work.

That'll still allow access to env vars, and interact with other processes owned by the same user.

At the very least, you really need to add process isolation / namespacing as well - at which point it's going to be easier to just use the sandboxing / containerisation tool of your choice to manage it all for you.

Re: NPM flooded with malicious packages downloaded more than 86k times

#239
post #58

Here's my `npm` command these days. It reduces the attack surface drastically. alias npm='docker run --rm -it -v ${PWD}:${PWD} --net=host --workdir=${PWD} node:25-bookworm-slim npm' - No access to my env vars - No access to anything outside my current directory (usually a JS project). - No access to my .bashrc or other files. Ref: https://ashishb.net/programming/run-tools-inside-docker/

Not sure how secure this really is, because it's fairly easy to break out of a Docker container with the default settings (due to the fact that the kernel is shared between containers and the host, unlike with VMs). Rootless Docker (or better, Podman) would improve security greatly.

Re: NPM flooded with malicious packages downloaded more than 86k times

#240
post #25
post #19

Earlier quoted context omitted.

Now you have the opposite problem, where a vulnerability could be found in one of your dependencies but you don't get the fix until the next "normal time that you verify that your program actually needs the update".

If a security issue is found that creates the "normal time". That is, when a security issue is found, regardless of supply chain tooling one would update. That there is a little cache/mirror thing in the middle is of little consequence in that case. And for all other cases the blessed versions in your mirror are better even if not latest.

This is how most software used to work before internet package managers, and it turns out that the same people who aren't good at checking their dependencies before automatically upgrading are also not good at constantly monitoring their dependencies for vulnerabilities.
Post reply on HN