Live data from Hacker News

NPM flooded with malicious packages downloaded more than 86k times

arstechnica.com

11–20 of 308 posts

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

#11

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…

> 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 ladder but not nearly as bad as the user-submitted madness outside Linux).

But it seems like your question is about front end web development, and that's not my world and I have no advice beyond sympathy.

> occasionally I’ll build a little thing that is neat and could be useful to someone else, but then I worry that I’m just a target for some bot

Pretty much that's the problem exactly. Distributing software is hard. It's a lot of work at a bunch of different levels of the process, and someone needs to commit to doing it. If you aren't willing to commit your time and resources, don't distribute it in a consumable way (obviously you can distribute what you built with it, and if it's appropriately licensed maybe someone else will come along and productize it).

NPM thought they could hack that overhead and do better, but it turns out to have been a moved-too-fast-and-broke-things situation in hindsight.

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

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

That is exactly what I do.

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

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

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

#14
post #11

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…

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

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

#15
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're describing a custom registry. These exist IRL (eg jFrog Artifactory). Useful for managing allow-listed packages which have met whatever criteria you might have (eg CVE-free based on your security tool of choice). Use of a custom registry, and a sane package manager (pnpm, not npm), and its lockfile, will significantly enhance your supply-chain security.

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

#16

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…

Use dependencies that are fairly popular and pick a release that's at least a year old. Done. If there was something wrong with it, someone would've found it by now. For a hobbyist, that's more than sufficient.

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

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

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

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

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

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

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

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

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

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

Well in the Java world, Maven had custom repositories which did this for the last 20+ years.
Post reply on HN