Malicious versions of Nx and some supporting plugins were published • Hacker News Board

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

#331

Post by xmodem » Wed, Aug 27, 2025, 9:14 PM UTC

mixedbit wrote: post #314

I'm afraid that open source software supply chain attacks could be much more prevalent than what we are currently aware of. There is a significant market for zero-day exploits, with organizations like the NSA having teams dedicated to collecting and weaponizing them. But finding and exploiting an unintentional zero-day vulnerability is way more difficult than adding an intentional exploitable bug or backdoor to some…

Every time one of these comes up, I have similar thoughts. A threat actor is in the position to pull off a large-scale supply chain compromise, and the best thing you can think of to do with that is also the thing that will guarantee you are discovered immediately? Mine crypto on the damn CPU, or publicly post the victim's credentials to their own GitHub account?

On one hand, I cannot accept that the actors that we see who pull these off are the best and brightest. My gut tells me that these attacks must be happening in more subtle ways from time to time. Maybe they're more targeted, maybe they're not but just have more subtle exfil mechanisms.

On the other, well we have exactly one data point of an attempt at a more subtle attack. And it was thwarted right before it started to see wide-spread distribution.

But also there was a significant amount of luck involved. And what if it hadn't been discovered? We'd still have zero data points, but some unknown actor would possess an SSH skeleton key.

So I don't know what to think.

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

#332

Post by quotemstr » Wed, Aug 27, 2025, 9:14 PM UTC

hombre_fatal wrote: post #235

0xbadcafebee wrote: post #64

Before anyone puts the blame on Nx, or Anthropic, I would like to remind you all what actually caused this exploit. The exploit was caused by an exploit, shipped in a package, that was uploaded using a stolen "token" (a string of characters used as a sort of "usename+password" to access a programming-language package-manager repository). But that's just the delivery mechanism of the attack. What caused the attack to…

One thing that's weirdly precarious is how we still have one big environment for personal computing and how it enables most malware. It's one big macOS/Windows/Linux install where everything from crypto wallets to credential files to gimmick apps are all neighbors. And the tools for partitioning these things are all pretty bad (and mind you I'm about to pitch something probably even worse). When I'm running a few Win…

> One thing that's weirdly precarious is how we still have one big environment for personal computing and how it enables most malware.

You're not the only one to note the dangers of an open-by-default single-namespace execution model. Yet every time someone proposes departing from it, he generates resistance from people who've spent their whole careers with every program having unbridled access to $HOME. Even lightweight (and inadequate) sandboxing of the sort Flatpak and Snap do gets turned off the instant someone thinks it's causing a problem.

On mobile, we're had containerized apps and they've worked fine forever. The mobile ecosystem is more secure and has a better compatibility story than any desktop. Maybe, after the current old guard retires, we'll be able to replace desktop OSes with mobile ones.

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

#333

Post by inbx0 » Wed, Aug 27, 2025, 9:15 PM UTC

andix wrote: post #299

inbx0 wrote: post #125

Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…

I guess this won't help with something like nx. It's a CLI tool that is supposed to be executed inside the source code repo, in CI jobs or on developer pcs.

According to the description in advisory, this attack was in a postinstall script. So it would've helped in this case with nx. Even if you ran the tool, this particular attack wouldn't have been triggered if you had install scripts ignored.

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

#334

Post by quotemstr » Wed, Aug 27, 2025, 9:16 PM UTC

chatmasta wrote: post #330

hombre_fatal wrote: post #235

Earlier quoted context omitted.

One thing that's weirdly precarious is how we still have one big environment for personal computing and how it enables most malware. It's one big macOS/Windows/Linux install where everything from crypto wallets to credential files to gimmick apps are all neighbors. And the tools for partitioning these things are all pretty bad (and mind you I'm about to pitch something probably even worse). When I'm running a few Win…

macOS at least has some basic sandboxing by default. You can circumvent it, of course – and many of the same people complaining about porous security models would complain even more loudly if they could not circumvent it, because “we want to execute code on our own machine” (the tension between freedom and security). By default, folders like ~/Documents are not accessible by any process until you explicitly grant acc…

> By default, folders like ~/Documents are not accessible by any process until you explicitly grant acces

And in a terminal, the principal to which you grant access to a directory is your terminal emulator, not the program you're trying to run. That's bonkers and encourages people to just click "yes" without thinking. And once you're authorized your terminal to access documents once, everything you run in it gets that access.

The desktop security picture is improving, slowly and haltingly, for end-user apps, but we haven't even begun to attempt to properly sandbox development workflows.

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

#335

Post by VPenkov » Wed, Aug 27, 2025, 9:17 PM UTC

ZeWaka wrote: post #323

VPenkov wrote: post #321

Earlier quoted context omitted.

Not a package manager, but Renovate bot has a setting like that (minimumReleaseAge). Dependabot does not (Edit: does now). So while your package manager will install whatever is newest, there are free solutions to keep your dependencies up to date in a reasonable manner. Also, the javascript ecosystem seems to slowly be going in the direction of consolidation, and supply chain attacks are (again, slowly) getting tool…

Dependabot got it last month, actually. https://github.blog/changelog/2025-07-01-dependabot-supports...

Oh, happy days!

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

#336

Post by quotemstr » Wed, Aug 27, 2025, 9:18 PM UTC

JdeBP wrote: post #300

hombre_fatal wrote: post #235

Earlier quoted context omitted.

One thing that's weirdly precarious is how we still have one big environment for personal computing and how it enables most malware. It's one big macOS/Windows/Linux install where everything from crypto wallets to credential files to gimmick apps are all neighbors. And the tools for partitioning these things are all pretty bad (and mind you I'm about to pitch something probably even worse). When I'm running a few Win…

I am told that the SmartOS people have this sort of idea. * https://wiki.smartos.org

> SmartOS is a specialized Type 1 Hypervisor platform based on illumos.

On Solaris? Why? And why bother with a Type 1 hypervisor? You get the same practical security benefits with none of the compatibility headaches (or the headaches of commercial UNIX necromancy) by containerizing your workloads. You don't need a hypervisor for that. All the technical pieces exist and work fine. You're solving a social problem, not a technical one.

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

#337

Post by throwmeaway222 » Wed, Aug 27, 2025, 9:20 PM UTC

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…

I've been saying this for a while, llms will get rid of a lot of libraries, rightly so.

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

#338

Post by herpdyderp » Wed, Aug 27, 2025, 9:21 PM UTC

inbx0 wrote: post #125

Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…

Unfortunately this also blocks your own life cycle scripts.

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

#339

Post by nawgz » Wed, Aug 27, 2025, 9:22 PM UTC

dvfjsdhgfv wrote: post #304

mirekrusin wrote: post #290

Earlier quoted context omitted.

workspace protocol in monorepo is also great, we're using it a lot.

OK so it seems too good now, what are the downsides?

‘pnpm’ is great, swapped to it a year ago after yarn 1->4 looked like a new project every version and npm had an insane dependency resolution issue for platform specific packages

pnpm had good docs and was easy to put in place. Recommend

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

#340

Post by chatmasta » Wed, Aug 27, 2025, 9:27 PM UTC

quotemstr wrote: post #334

chatmasta wrote: post #330

Earlier quoted context omitted.

macOS at least has some basic sandboxing by default. You can circumvent it, of course – and many of the same people complaining about porous security models would complain even more loudly if they could not circumvent it, because “we want to execute code on our own machine” (the tension between freedom and security). By default, folders like ~/Documents are not accessible by any process until you explicitly grant acc…

> By default, folders like ~/Documents are not accessible by any process until you explicitly grant acces And in a terminal, the principal to which you grant access to a directory is your terminal emulator, not the program you're trying to run. That's bonkers and encourages people to just click "yes" without thinking. And once you're authorized your terminal to access documents once, everything you run in it gets tha…

Yeah, it does say “Do you want to grant Terminal.app access to ~/Documents?”

I agree this should be more granular to the actual process/binary attempting the access. Or at least there should be an option like on iOS, to grant access but “just this once.” That way you know it’s the program you just ran, but you aren’t granting access to any program you execute in the terminal in perpetuity.

But I’ve yet to grant it since I treat that prompt as an indication I should move the files I’m trying to access into a different directory.