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

Malicious npm packages detected across Red Hat Cloud Services

github.com

Post reply on HN
Print view View original

311–320 of 494 posts

Re: Malicious npm packages detected across Red Hat Cloud Services

#311

Post by hedora »

eranation wrote: post #298
Normal_gaussian wrote: post #284

Earlier quoted context omitted.

> If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. This feels like a very very small group of people; and people who really could do with opening the file and adding the line.

I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the ca…

In what way is "edit your .npmrc" simple?!?

The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc.

Every one of those has a different opinion about how to spell "cooldown".

On top of that, there's the bootstrapping issue of "I want to install the N pieces of ecosystem sprawl that read the .[p]npmrc that have the cooldown directive in them. How do I do that with a cooldown?" (Where N is unknowable, because of course it is.)

Re: Malicious npm packages detected across Red Hat Cloud Services

#312

Post by johannes1234321 »

oblio wrote: post #206
johannes1234321 wrote: post #107

Earlier quoted context omitted.

> Furthering the idea that not all package managers are the same, there are entire cycles of the moon where I don't open nuget once. Some ecosystems simply don't need to vendor out very often, and these are the ones where you generally find the least news like this. This however is only to some degree the package manager's fault. The JavaScript culture is strongly ordering tiny packages by individual people doing sma…

> That small package mentality a trace to web usage: JavaScript code is often sent to the client, not having a huge library but having small dedicated libraries means that it is a lot simpler for the bundler to not bundle dead code which is sent to the browser client. Which is another part of this entire insanity: Browsers are already >. They're also built by > companies companies that collect > of analytics. You'd t…

That was circumvented once by CDNs hosting common libraries so that those would stay in browser cache, browser vendors then "broke" that by caching per origin. (So that an evil site can't detect whether a user had been on some target site before by testing whether assets are fetched from cache)

Issue probably is that the standards process is slow (unless it is a feature Google "needs") and full of bike shedding (which features and how exactly they'd look) and adaption of features by developers is slow.

JavaScript meanwhile should be stable enough as an environment to allow a broader standard library.

Luckily it is slowly getting better (see Temporal as new date library, replacing moment.js usage in many places)

Re: Malicious npm packages detected across Red Hat Cloud Services

#313

Post by bandrami »

icedchai wrote: post #287
bandrami wrote: post #282

Earlier quoted context omitted.

You mean directly on the machine? Not in a container? That would be a recklessly fast timeline. The configuration control board meets quarterly and it usually takes 4 or 5 meetings to clear a piece of software.

Interesting. How about in a container? What industry is this, just curious?

Defense. Containers on our normal network are the wild west, but anything that touches the secure network has to be signed off on by the clients.

Re: Malicious npm packages detected across Red Hat Cloud Services

#314

Post by bakkoting »

hedora wrote: post #304
bakkoting wrote: post #299

Earlier quoted context omitted.

They have taken action as of very recently. The latest version [1] of npm warns when there are install scripts and tells you they will be disabled by default in a future version, with a per-dependency opt in mechanism [2]. [1] https://github.com/npm/cli/releases/tag/v11.16.0 [2] https://github.com/npm/rfcs/pull/868

This is way too little, way too late. To see what I mean, try actually packaging a cross-platform binary dependency in their ecosystem.

I have; you specify one optional dependency per platform and set the requirements in each package. It works fine. A bunch of packages do this (e.g. esbuild). I don't know what your complaint is or what you're asking for.

Re: Malicious npm packages detected across Red Hat Cloud Services

#315

Post by pixl97 »

exitb wrote: post #21
Tomte wrote: post #15

Earlier quoted context omitted.

You rely on the security companies scanning the packages.

Well, if that actually works, it should be part of the release process, before the packages get placed onto the regular channels.

It works because there are multiple companies doing it and double checking the results.

For example, is a crypto miner actually an attack? If the package presents itself as a miner, then no. Is connections to other repositories an attack? Again, depends on what the package does. Connections to some other hostname? Depends.

There is still a lot of human analysis that occurs in making the call that an attack is occurring.

Re: Malicious npm packages detected across Red Hat Cloud Services

#316

Post by pixl97 »

insanitybit wrote: post #135

Just some suggestions: 1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs. 2. Anywhere you have `npm install` or `npm test` or anything where code executes , that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and tes…

>install the latest version of zizmor.

What if it gets compromised?

More of a joke. But was funny after saying that new packages should be delayed.

Re: Malicious npm packages detected across Red Hat Cloud Services

#317

Post by StilesCrisis »

eranation wrote: post #298
Normal_gaussian wrote: post #284

Earlier quoted context omitted.

> If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. This feels like a very very small group of people; and people who really could do with opening the file and adding the line.

I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the ca…

An extra $15 of labor is well worth the cost of not having to change my own oil. They will do it efficiently and won't break anything. The cost of messing up one time immediately cancels out a lifetime of DIY savings, and they are equipped to do it right.

Re: Malicious npm packages detected across Red Hat Cloud Services

#318

Post by dbdr »

genxy wrote: post #190
JoshTriplett wrote: post #20

Earlier quoted context omitted.

A large array of automated and semi-automated security scanners are finding things quickly. The main benefit of waiting before updating is to give those scanners time to work.

Would be nice if cargo had a cooldown flag and could respect lockfiles by default.

min-publish-age in cargo is coming:

https://github.com/rust-lang/rfcs/blob/master/text/3923-carg...

Re: Malicious npm packages detected across Red Hat Cloud Services

#319

Post by Normal_gaussian »

eranation wrote: post #298
Normal_gaussian wrote: post #284

Earlier quoted context omitted.

> If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. This feels like a very very small group of people; and people who really could do with opening the file and adding the line.

I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the ca…

> Changing your own car's oil is actually not that hard

It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance.

> Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers.

Exactly. Using a QR code app required specific knowledge of the app, an internet connection, some time, knowledge of how and when to use it, and something to use it with - the barrier of which surpassed the convenience gained from the QR code.

> So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)

I'm struggling to find a non-contrived group of people who:

- do not know how to open and edit a file on their system

- do use npm

- would find installing pnpm or running `sudo install -d -m 0755 /etc/apt/keyrings; curl -fsSL https://depsguard.com/apt/gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/depsguard.gpg; echo "deb [signed-by=/etc/apt/keyrings/depsguard.gpg] https://depsguard.com/apt stable main" | sudo tee /etc/apt/sources.list.d/depsguard.list >/dev/null; sudo apt update; sudo apt install depsguard` simpler

Of course, cooldowns.dev is a very long winded way of telling someone to run `npm config set min-release-age=3`, which is the simplest.

Post reply on HN