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

Malicious versions of Nx and some supporting plugins were published

github.com

Post reply on HN
Print view View original

261–270 of 460 posts

Re: Malicious versions of Nx and some supporting plugins were published

#261

Post by hvb2 »

3036e4 wrote: post #180
hvb2 wrote: post #121

Earlier quoted context omitted.

That's what a package is supposed to solve, no? Sure there are packages trying to solve 'the world' and as a result come with a whole lot of dependencies, but isn't that on whoever installs it to check? My point was that git clone of the source can't be the solution, or you own all the code... And you can't. You always depend on something....

Your dependencies are also part of your product and your full responsibility. No one you deliver a product to will accept "it wasn't my code, it was in a dependency of one of my dependencies" as an excuse. Of course you need to depend on things, but it is insane to not keep that to a minimum.

So you're expecting to see every product affected by this to go and do a big mea culpa because one of their dependencies broke?

Like how xz was attacked, everyone pointed at that and no one said they didn't vet their dependencies.

That's the whole point, you attack a dependency that everyone relies on because it's been good and stable. That's how these pyramids build up over time.

So spoiler, it's not unlikely one of the dependencies in your minimal set gets exploited...

Re: Malicious versions of Nx and some supporting plugins were published

#262

Post by 0cf8612b2e1e »

christophilus wrote: post #63
roenxi wrote: post #4

Honest to goodness, I do most of my coding in a VM now. I don't see how the security profile of these things are tolerable. The level of potential hostility from agents as a malware vector is really off the charts. We're entering an era where they can scan for opportunities worth >$1,000 in hostaged data, crypto keys, passwords, blackmail material or financial records without even knowing what they're looking for whe…

Similar, but in a podman container which shares nothing other than the source code directory with my host machine.

I would love if some experts could comment on the security profile of this. It sounds like it should be fine, but there are so many gotchas with everything that I use full VMs for development.

One immediate stumbling block- the IDE would be running in my host, which has access to everything. A malicious IDE plugin is a too real potential vector.

Re: Malicious versions of Nx and some supporting plugins were published

#263

Post by sheerun »

coldpie wrote: post #54
f311a wrote: post #11

People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simpl…

> People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. I was really nervous when "language package managers" started to catch on. I work in the systems programming world, not the web world, so for the past decade, I looked from a distance at stuff like pip and npm and whatever with kind of a questionable side-eye. But when I did a Rust project and saw how tr…

Back as in using less dependencies or throwing bunch of "certifying" services at all of them?

Re: Malicious versions of Nx and some supporting plugins were published

#264

Post by 0cf8612b2e1e »

fwip wrote: post #255
kasey_junk wrote: post #56

Earlier quoted context omitted.

I definitely think running agents in sandboxes is the way to go. That said Claude code does not have free reign to run commands out of the gate.

Pet peeve - it's free rein, not free reign. It's a horse riding metaphor.

Bah, well I have been using that incorrectly my entire life. A monarchy/ruler metaphor seems just as logical.

Re: Malicious versions of Nx and some supporting plugins were published

#265

Post by freedomben »

cluckindan wrote: post #178
freedomben wrote: post #142

Earlier quoted context omitted.

If you can execute code on some machine without having access to that machine, then it's RCE. Whether you gain RCE through an exploit in a bad network protocol or through tricking the user into running your code (i.e. this attack) is merely a delivery mechanism. It's still RCE

Not exactly. A supply chain attack can be used to deliver RCE enabling payloads such as a reverse shell, but in itself, it is not considered RCE. RCE implies ability to remotely execute arbitrary code on an affected system at will.

> A supply chain attack can be used to deliver RCE enabling payloads such as a reverse shell, but in itself, it is not considered RCE.

Yes, as I tried to make clear above, these are orthogonal. The supply chain attack is NOT an RCE, it's a delivery mechanism. The RCE is the execution of the attacker's code, regardless how it got there.

> RCE implies ability to remotely execute arbitrary code on an affected system at will.

We'll have to disagree on this one, unless one of us can cite a definition from a source we can agree on. Yes frequently RCE is something an attacker can push without requiring the user to do something, but I don't think that changes the nature of the fact that you are achieving remote code execution. Whether the user triggers the execution of your code by `npm install`ing your infected package or whether the attacker triggers it by sending an exploitative packet to a vulnerable network service isn't a big enough nuance in my opinion to make it not be RCE. From that perspective, the user had to start the vulnerable service in the first place, or even turn the computer on, so it still requires some user (not the attacker) action before it's vulnerable.

Re: Malicious versions of Nx and some supporting plugins were published

#266

Post by chuckadams »

wat10000 wrote: post #224
chuckadams wrote: post #104

Earlier quoted context omitted.

So, what's the acceptable LOC count threshold for using a library? Maybe scolding and mocking people isn't a very effective security posture after all.

Time for everybody's favorite engineering answer: it depends! You have to weigh the cost/benefit tradeoff. But you have to do it in full awareness of the costs, including potential costs from packages being taken down, broken, or subverted. In any case, for an external dependency, 100 lines is way too low of a benefit. I'm not trying to be effective, I'm just lamenting. Maybe being sarcastic isn't a very effective wa…

Naw, sarcasm totally works... ;)

I'd say it all depends -- there's that word again -- on what those 100 LOC are expressing. I suppose one could still copy/paste such a small amount of code, but I'd rather just check in some subset of vendored dependencies. Or maybe just pin the dependency to a commit hash (since we can't depend on version tags being immutable). Something actionable beyond peer pressure at any rate.

Re: Malicious versions of Nx and some supporting plugins were published

#267

Post by SpaceManNabs »

so the malware launches AI tools that have wider access than the app is loaded in?

I did not know AI tools could access sensitive directories.

Or is it that AI brute forces access to directories that the malware already had access to but the developer of the malware was not aware of?

Does the inventory.txt get uploaded? There seems to be an outbound connection but I did not see verification that it is the inventory.txt.

Re: Malicious versions of Nx and some supporting plugins were published

#268

Post by mr_mitm »

skydhash wrote: post #138
mr_mitm wrote: post #133

Earlier quoted context omitted.

Simply running the software means trusting the developer. But even then, do you really read the commits comprising the latest Firefox update? How would I review the updates for my cell phone? I just hit "okay", or simply set up auto updates.

I trust Debian, and I do trust Firefox. I also trust Node, NPM, and Yarn. But I don’t trust the myriad packages in some rando projects. So who I trust got installed by apt. Anyone else is relocated to a VM or some kind of sandbox.

So your issue isn't related to auto updates at all, not even "almost always"

Re: Malicious versions of Nx and some supporting plugins were published

#269

Post by [deleted] »

tremon wrote: post #220
chuckadams wrote: post #162

Earlier quoted context omitted.

I don't think we're going to reach a point where "don't use dependencies at all" is a rational argument for most projects.

It's a good thing then that was not among the rational arguments I was referring to. Do you have other straw men on offer?

[deleted]

Re: Malicious versions of Nx and some supporting plugins were published

#270

Post by smohare »

coldpie wrote: post #54
f311a wrote: post #11

People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simpl…

> People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year. I was really nervous when "language package managers" started to catch on. I work in the systems programming world, not the web world, so for the past decade, I looked from a distance at stuff like pip and npm and whatever with kind of a questionable side-eye. But when I did a Rust project and saw how tr…

[dead]
Post reply on HN