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

NPM flooded with malicious packages downloaded more than 86k times

arstechnica.com

Post reply on HN
Print view View original

181–190 of 308 posts

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

#181

Post by arghwhat »

ashishb wrote: post #133
fragmede wrote: post #127

Earlier quoted context omitted.

Am I missing something? Don't you also need to change how CI and deployment processes call npm? If my CI server and then also my deployment scripts are calling npm the old insecure way, and running infected install scripts/whatever, haven't I just still fucked myself, just on my CI server and whatever deployment system(s) are involved? That seems bad.

Your machine has more projects, data, and credentials than your CI machine, as you normally don't log into Gmail on your CI. So, just protecting your machine is great. Further, you are welcome to use this alias on your CI as well to enhance the protection.

Attacking your CI machines means to poison your artifacts you ship and systems they get deployed to, get access to all source it builds and can access (often more than you have locally) and all infrastructure it can reach.

CI machines are very much high-value targets of interest.

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

#182

Post by tetha »

phiresky wrote: post #68
ashishb wrote: 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/

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.

At work, we're currently looking into firejail and bubblewrap a lot though and within the ops-team, we're looking at ways to run as much as possible, if not everything through these tools tbh.

Because the counter-question could be: Why would anything but ssh or ansible need access to my ssh keys? Why would anything but firefox need access to the local firefox profiles? All of those can be mapped out with mount namespaces from the execution environment of most applications.

And sure, this is a blacklist approach, and a whitelist approach would be even stronger, but the blacklist approach to secure at least the keys to the kingdom is quicker to get off the ground.

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

#183

Post by CraigJPerry »

codedokode wrote: post #155
scuff3d wrote: post #140

Earlier quoted context omitted.

One of the biggest things that pushes me away from Rust is the reliance on micro dependencies. It's a terrible model.

What's wrong with micro dependencies? Isn't it better to download only the code you need? Also it makes refactoring easier, and enforces better architecture.

Larger attack surface - you just need one of those N dependencies to fall for a spear phishing attack and you're cooked. Larger N is necessarily worse.

It depends on the software being written, but if it's a product your business sells or otherwise has an essential dependency on, then the best model available right now is vendoring dependencies.

You still get all the benefits of standing on top of libraries and frameworks of choice, but you've introduced a single point of entry for externally authored code - there are many ways you can leverage that to good effect (vuln scans, licence audits, adding patch overlays etc etc) and you improved the developer experience - when they check out the code, ALL of the code to build and run the project is already present, no separate npm install step.

You can take this model quite a bit further and buy some really useful capabilities for a development team, like dependency upgrades because they're a very deliberate thing now, you can treat them like any other PR to your code base - you can review the changes of each upgrade easily.

There's challenges too - maybe your npm dep builds a native binary as part of it, you now need to provide that build infra / tooling, and very likely you also want robust build artifact and test caching to save wasting lots of time.

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

#186

Post by 2d8a875f-39a2-4 »

The npm ecosystem's approach to supply chain security is criminally negligent. For the critical infrastructure that underpins the largest attack surface on the Internet you would think that this stuff would be priority zero. But nope, it's failing in ways that are predictable and were indeed predicted years ago. I'm not closely involved enough with the npm community to suggest what the next steps should be but something has to change, and soon.

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

#188

Post by jve »

ashishb wrote: post #76
phiresky wrote: post #68

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…

You do the backward logic here. I would go for a single person to deal with pnpm migration and CI rather than instruct other 10 for everyone to hopefully do the right thing. And think about it when the next person comes in... so I'd go for the first option for sure.

And npm can be configured to prevent install scripts to be run anyways:

> Consider adding ignore-scripts to your .npmrc project file, or to your global npm configuration.

But I do like your option to isolate npm for local development purposes.

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

#189

Post by fragmede »

ashishb wrote: post #133
fragmede wrote: post #127

Earlier quoted context omitted.

Am I missing something? Don't you also need to change how CI and deployment processes call npm? If my CI server and then also my deployment scripts are calling npm the old insecure way, and running infected install scripts/whatever, haven't I just still fucked myself, just on my CI server and whatever deployment system(s) are involved? That seems bad.

Your machine has more projects, data, and credentials than your CI machine, as you normally don't log into Gmail on your CI. So, just protecting your machine is great. Further, you are welcome to use this alias on your CI as well to enhance the protection.

> Further, you are welcome to use this alias on your CI as well to enhance the protection.

Yes, but if I've got to configure that across the CI fleet as well as in my deploy system(s) in order to not get, and also be distributing malware, what's the difference between having to do that vs switching to pnpm in all the same places?

Or more explicitly, your first point is invalid. Whether you ultimately choose to use docker to run npm or switch to pnpm, it doesn't count to half-ass the fix and only tell your one friend on the team to switch, you have to get all developers to switch AND fix your CI system, AND also your deployment system (s) (if they are exposed).

This comment proffers no option on which of the two solutions should be preferred, just that the fix needs to made everywhere.

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

#190

Post by lioeters »

Defletter wrote: post #134
nektro wrote: post #113

Earlier quoted context omitted.

this is one of the less talked about benefits of using bun

How does Bun avoid this? Or is it more that Bun provides things that you'd otherwise need a dependency for (eg: websockets)?

From a link mentioned elsewhere in the thread:

> Unlike other npm clients, Bun does not execute arbitrary lifecycle scripts for installed dependencies, such as `postinstall` and `node-gyp` builds. These scripts represent a potential security risk, as they can execute arbitrary code on your machine.

https://bun.com/docs/guides/install/trusted

I've also found the Bun standard library is a nice curated set of features that reduces dependencies.

Post reply on HN