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

61–70 of 460 posts

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

#61

Post by christophilus »

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’d like a package manager that essentially does a git clone, and a culture that says: “use very few dependencies, commit their source code in your repo, and review any changes when you do an update.” That would be a big improvement to the modern package management fiasco.

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

#62

Post by sneak »

kasey_junk wrote: post #56
snovymgodym wrote: post #55

Claude code is by all accounts a revolutionary tool for getting useful work done on a computer. It's also: - a NodeJS app - installed by curling a shell script and piping it into bash - an LLM that's given free reign to mess with the filesystem, run commands, etc. So that's what, like 3 big glaring vectors of attack for your system right there? I would never feel comfortable running it outside of some kind of sandbox…

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.

Yes it does; you are thinking of agent tool calls. The software package itself runs as your uid and can do anything you can do (except on macOS where reading of certain directories is individually gated).

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

#63

Post by christophilus »

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.

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

#64

Post by 0xbadcafebee »

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.

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

#65

Post by cedws »

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…

Rust makes me especially nervous due to the possibility of compile-time code execution. So a cargo build invocation is all it could take to own you. In Go there is no such possibility by design.

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

#66

Post by christophilus »

sneak wrote: post #60
snovymgodym wrote: post #55

Claude code is by all accounts a revolutionary tool for getting useful work done on a computer. It's also: - a NodeJS app - installed by curling a shell script and piping it into bash - an LLM that's given free reign to mess with the filesystem, run commands, etc. So that's what, like 3 big glaring vectors of attack for your system right there? I would never feel comfortable running it outside of some kind of sandbox…

None of this is the concerning part. The bad part is that it auto-updates while running without intervention - i.e. it is RCE on your machine for Anthropic by design .

Mine doesn’t auto update. I set it up so it doesn’t have permission to do that.

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

#67

Post by sneak »

terminalbraid wrote: post #48
vorgol wrote: post #20

OSs need to stop letting applications have a free reign of all the files on the file system by default. Some apps come with apparmor/selinux profiles and firejail is also a solution. But the UX needs to change.

Which operating system lets an application have "free reign of all the files on the file system by default"? Neither Linux, nor any BSD, nor MacOS, nor Windows does. For any of those I'd have to do something deliberately unsafe such as running it as a privileged account (which is not the "default").

https://www.xkcd.com/1200/

All except macOS let anything running as your uid read and write all of your user’s files.

This is how ransomware works.

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

#68

Post by arcfour »

echelon wrote: post #49
octo888 wrote: post #27

Earlier quoted context omitted.

A single top-level comment would suffice. No need to reply to various comments with the same kind of message

My first two comments in this thread were my initial reaction to what was happening. I made the above, longer form post to hopefully grab the attention of Google and Anthropic folks. My top-level posts always fall to the very bottom of the page. Google and Anthropic need to be tracking this.

Don't forget to file a bug report with the maintainers of Python, Bash, Node, Perl, Ruby, etc. that their interpreters can be used maliciously if given malicious code to execute.

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

#70

Post by [deleted] »

terminalbraid wrote: post #48
vorgol wrote: post #20

OSs need to stop letting applications have a free reign of all the files on the file system by default. Some apps come with apparmor/selinux profiles and firejail is also a solution. But the UX needs to change.

Which operating system lets an application have "free reign of all the files on the file system by default"? Neither Linux, nor any BSD, nor MacOS, nor Windows does. For any of those I'd have to do something deliberately unsafe such as running it as a privileged account (which is not the "default").

[deleted]
Post reply on HN