Most active commenters
  • quotemstr(3)

←back to thread

Malicious versions of Nx and some supporting plugins were published

(github.com)
441 points longcat | 12 comments | 27 Aug 25 01:38 UTC | HN request time: 0s | source | bottom
Show context
0xbadcafebee ◴[27 Aug 25 13:56 UTC] No.45039764[source]▶
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 be successful were:

  1. The package manager repository did not require signing of artifacts to verify they were generated by an authorized developer.
  2. The package manager repository did not require code signing to verify the code was signed by an authorized developer.
  3. (presumably) The package manager repository did not implement any heuristics to detect and prevent unusual activity (such as uploads coming from a new source IP or country).
  4. (presumably) The package manager repository did not require MFA for the use of the compromised token.
  5. (presumably) The token was not ephemeral.
  6. (presumably) The developer whose token was stolen did not store the token in a password manager that requires the developer to manually authorize unsealing of the token by a new requesting application and session.
Now after all those failures, if you were affected and a GitHub repo was created in your account, this is a failure of:

  1. You to keep your GitHub tokens/auth in a password manager that requires you to manually authorize unsealing of the token by a new requesting application and session.
So what really caused this exploit, is all completely preventable security mechanisms, that could have been easily added years ago by any competent programmer. The fact that they were not in place and mandatory is a fundamental failure of the entire software industry, because 1) this is not a new attack; it has been going on for years, and 2) we are software developers; there is nothing stopping us from fixing it.

This is why I continue to insist there needs to be building codes for software, with inspections and fines for not following through. This attack could have been used on tens of thousands of institutions to bring down finance, power, telecommunications, hospitals, military, etc. And the scope of the attacks and their impact will only increase with AI. Clearly we are not responsible enough to write software safely and securely. So we must have a building code that forces us to do it safely and securely.

replies(8): >>45040360 #>>45040456 #>>45040507 #>>45042587 #>>45043533 #>>45044094 #>>45047267 #>>45049695 #
1. hombre_fatal ◴[27 Aug 25 17:38 UTC] No.45042587[source]▶
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 Windows VMs inside macOS, I kinda get this vision of computing where we boot into a slim host OS and then alt-tab into containers/VMs for different tasks, but it's all polished and streamlined of course (an exercise for someone else).

Maybe I have a gaming container. Then I have a container I only use for dealing with cryptocurrency. And I have a container for each of the major code projects I'm working on.

i.e. The idea of getting my bitcoin private keys exfiltrated because I installed a VSCode extension, two applications that literally never interact, is kind of a silly place we've arrived in personal computing.

And "building codes for software" doesn't address that fundamental issue. It kinda feels like an empty solution like saying we need building codes for operating systems since they let malware in one app steal data from other apps. Okay, but at least pitch some building codes and what enforcement would look like and the process for establishing more codes, because that's quite a levitation machine.

replies(7): >>45043386 #>>45043392 #>>45044029 #>>45045353 #>>45045371 #>>45047763 #>>45050959 #
2. Gander5739 ◴[27 Aug 25 18:42 UTC] No.45043386[source]▶
Like Qubes?
replies(1): >>45049720 #
3. vgb2k18 ◴[27 Aug 25 18:43 UTC] No.45043392[source]▶
Agreed on the madness of wide open OS defaults, I share your vision for isolation as a first-class citizen. In the mean-time (for Windows 11 users) theres Sandboxie+ fighting the good fight. I know most here will be aware of its strengths and limitations, but for any who dont (or who forgot about it), I can say its still working just as great on Windows 11 like it did on Windows 7. While its not great isolating heavy-weight dev environments (Visual Studio, Unreal Engine, etc), its almost perfect for managing isolation of all the small suff (Steam games, game emulators, YouTube downloaders , basic apps of all kinds).
4. JdeBP ◴[27 Aug 25 19:33 UTC] No.45044029[source]▶
I am told that the SmartOS people have this sort of idea.

* https://wiki.smartos.org

replies(1): >>45045414 #
5. chatmasta ◴[27 Aug 25 21:13 UTC] No.45045353[source]▶
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 access. So as long as you run your code in some other folder you’ll at least be notified when it’s trying to access ~/Documents or ~/Library or any other destination with sensitive content.

It’s obviously not a panacea but it’s better than nothing and notably better than the default Linux posture.

replies(1): >>45045390 #
6. quotemstr ◴[27 Aug 25 21:14 UTC] No.45045371[source]▶
> 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.

7. quotemstr ◴[27 Aug 25 21:16 UTC] No.45045390[source]▶
> 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.

replies(1): >>45045501 #
8. quotemstr ◴[27 Aug 25 21:18 UTC] No.45045414[source]▶
> 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.

9. chatmasta ◴[27 Aug 25 21:27 UTC] No.45045501{3}[source]▶
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.

10. mayama ◴[28 Aug 25 02:44 UTC] No.45047763[source]▶
flatpak is supposed to address this. Running applications in sandbox. But, with almost all applications wanting access to your HOME, because of convenience, sandbox utility is quiet questionable in most cases.
11. miggol ◴[28 Aug 25 08:15 UTC] No.45049720[source]▶
Qubes really is the trailblazer in this regard. You can get pretty close with distroboxes on Linux as well.

When a project requires a certain Python version a virtualenv suffices. But when you need a specific Python and NPM version then I might as well make a distrobox. Set a custom home and the project is isolated, speaking only to my IDE over LSP, and also to my web browser I suppose.

This only protects the developer themselves of course, but it's a start.

12. christophilus ◴[28 Aug 25 11:42 UTC] No.45050959[source]▶
Not if you make podman your default way of isolating projects.