Live data from Hacker News

NPM flooded with malicious packages downloaded more than 86k times

arstechnica.com

21–30 of 308 posts

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

#21
post #13
post #7

Imagine if we had a system where you could just deposit the source code for a program you work on into a "depository". You could set it up so your team could "admit" the changes that have your approval, but it doesn't allow third parties to modify what's in your depository (even if it's a library that you're using that they wrote). When you build/deploy your program, you only compile/run third-party versions that hav…

You are describing BSD ports from the 90's. FreeBSD ports date back to 1993.

Also, Gentoo dating back to 2003.

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

#22
post #17
post #6

Earlier quoted context omitted.

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…

how hard would it be to say "upon first install, run do_sketchy_shit.sh to install requirements"?

People want package managers to do that for them. As much as I think it's often a mistake (if your stuff requires more than expanding archives different folders to install, then somewhere in the stack something has gone quite wrong), I will concede that because we live in an imperfect world, other folks will want the possibility to "just run the thing automatically to get it done." I hope we can get to a world where such hooks are no longer required one day.

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

#23
post #11

Earlier quoted context omitted.

> As a hobbyist how do I stay protected and in the loop for breaches like this? For the case of general software, "Don't use node" would be my advice, and by extension any packaging backend without external audit and validation. PyPI has its oopses too, Cargo is theoretically just as bad but in practice has been safe. The gold standard is Use The Software Debian Ships (Fedora is great too, arch is a bit down the ladd…

Having spent a year trying to develop against dependencies only provided by a debian release, it is really painful in practice. At some point you're going to need something that is not packaged, or newer than the packaged version in your release.

It really depends on what you're doing. But yes, if you want to develop in "The NPM Style" where you suck down tiny things to do little pieces of what you need (and those things suck down tiny things, ad infinitum) then you're naturally exposed to the security risks inherent with depending on an unaudited soup of tiny things.

You don't get secure things for free, you have to pay for that by doing things like "import and audit software yourself" or even "write simple utilities from scratch" on occasion.

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

#24
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…

I seem to recall Husky at one point using lifecycle hooks to install the git hooks configured in your repository when running NPM install.

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

#25
post #19
post #7

Imagine if we had a system where you could just deposit the source code for a program you work on into a "depository". You could set it up so your team could "admit" the changes that have your approval, but it doesn't allow third parties to modify what's in your depository (even if it's a library that you're using that they wrote). When you build/deploy your program, you only compile/run third-party versions that hav…

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.

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

#26
post #18

Earlier quoted context omitted.

One use case is downloading of binaries. For example mongo-memory-server [0] will download the mongoDB binary after you have installed it. [0] https://www.npmjs.com/package/mongodb-memory-server

why would i want that though, compared to downloading that binary in the install download? the npm version is decoupled from the binary version, when i want them locked together

I think it falls into a few buckets:

A) maintainers don’t know any better and connect things with string and gum until it most works and ship it

B) people who are smart, but naive and think it will be different this time

C) package manager creators who think they’re creating something that hasn’t been done before, don’t look at prior art or failures, and fall into all of the same holes literally every other package manager has fallen into and will continue to fall into because no one in this industry learns anything.

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

#27

As a hobbyist how do I stay protected and in the loop for breaches like this? I often follow guides that are popular and written by well-respected authors and I might be too flippant with installing dependencies trying to solve a pain point that has derailed my original project. Somewhat related, I also have a small homelab running local services and every now and then I try a new technology. occasionally I’ll build…

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 not only sandboxing your code, but also making your dev environments repeatable.

If you are using GitHub, use codespaces. If you are using gitlab, workspaces. If you are using neither, check out tools like UTM or Vagrant.

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

#28

As a hobbyist how do I stay protected and in the loop for breaches like this? I often follow guides that are popular and written by well-respected authors and I might be too flippant with installing dependencies trying to solve a pain point that has derailed my original project. Somewhat related, I also have a small homelab running local services and every now and then I try a new technology. occasionally I’ll build…

There are some operating systems, like FreeBSD, where you use the system’s package manager and not a million language specific package managers.

I still maintain pushing this back to library authors is the right thing to do instead of making this painful for literally millions of end-users. The friction of getting a package accepted into a critical mass of distributions is the point.

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

#29
post #17

Earlier quoted context omitted.

how hard would it be to say "upon first install, run do_sketchy_shit.sh to install requirements"?

People want package managers to do that for them. As much as I think it's often a mistake (if your stuff requires more than expanding archives different folders to install, then somewhere in the stack something has gone quite wrong), I will concede that because we live in an imperfect world, other folks will want the possibility to "just run the thing automatically to get it done ." I hope we can get to a world where…

yes that's why npm is for them. I'd rather download the libraries that I need one by one.
Post reply on HN