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

201–210 of 460 posts

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

#201

Post by orblivion »

mikepurvis wrote: post #165
fsflover wrote: post #46

Earlier quoted context omitted.

I never used snaps, so I don't understand what you mean here. Here's a couple of typical Qubes usage patterns: https://www.qubes-os.org/news/2022/10/28/how-to-organize-you... , https://blog.invisiblethings.org/2011/03/13/partitioning-my-...

One of the biggest ones is around access to the home directory, ~/.whatever, that kind of thing. Like a browser downloads something, a text editor opens it, it gets run from the terminal and creates a new executable, that new executable is run and mutates something else that the text editor also had open, etc etc. If all the apps have access to ~ then it's https://xkcd.com/1200/ and there's basically no point in the…

As for setting things up multiple times - you can install stuff in the "Template VM" which is where the OS goes. Every "App VM" mostly just has files in their own ~/. Any changes an App VM makes to its system files won't affect other VMs, or even survive a restart. There are "playbooks" with Salt but I never figured that stuff out. If you pass around some setup scripts instead, that's an attack vector, but I don't think drive-by attacks like the OP would target something sophisticated like that yet.

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

#202

Post by bapak »

ec109685 wrote: post #192
nicoritschel wrote: post #182

One of my projects uses an impacted version. However, we use bun as a package manager. Thrilled bun protected us by default! > executing arbitrary scripts represents a potential security risk, so—unlike other npm clients—Bun does not execute arbitrary lifecycle scripts by default.

Can’t the exploit just be encoded in files that are used when the npm module is actually used? It seems like not running it at package install time doesn’t afford that much protection.

Correct. Pretty limited as a protection when the first thing you do after installing a package is running it.

Literally the only thing blocking scripts protects you from is if a package is bundled by webpack and not run by node. If the compromise happens in nx, it's just run after up type nx[enter] in your command line.

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

#203

Post by ajross »

skydhash wrote: post #71
coldpie wrote: post #54

Earlier quoted context omitted.

> 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…

The thing is, system based package managers require discipline, especially from library authors. Even in the web world, it’s really distressing when you see a minor library is already on its 15 iteration in less that 5 years. I was trying to build just (the task runner) on Debian 12 and it was impossible. It kept complaining about rust version, then some libraries shenanigans. It is way easier to build Emacs and ffmp…

Indeed, it seems insane that we're pining for the days of autotools, configure scripts and the cleanly inspectable dependency structure.

But... We absolutely are.

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

#204

Post by skybrian »

cluckindan wrote: post #42
grav wrote: post #32

> Interestingly, the malware checks for the presence of Claude Code CLI or Gemini CLI on the system to offload much of the fingerprintable code to a prompt. Can anyone explain this? Why is it an advantage?

The malware is not delivering any exploits or otherwise malicious-looking code, so endpoint security is unlikely to flag it as malicious.

That’s because it’s new. Perhaps feeding prompts into Claude Code and similar tools will be considered suspicious from now on?

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

#205

Post by maerch »

echelon wrote: post #23
fooqux wrote: post #21

Earlier quoted context omitted.

> Hopefully the LLM vendors issue security statements shortly. If they don't, that'll be pretty damning. Why would it be damning? Their products are no more culpable than Git or the filesystem. It's a piece of software installed on the computer whose job is to do what it's told to do. I wouldn't expect it to know that this particular prompt is malicious.

Then safety and alignment are a farce and these are not serious tools. This is 100% within the responsibility of the LLM vendors. Beyond the LLM, there is a ton of engineering work that can be put in place to detect this, monitor it, escalate, alert impacted parties, and thwart it. This is literally the impetus for funding an entire team or org within both of these companies to do this work. Cloud LLMs are not interp…

I’m really trying to understand your point, so please bear with me.

As I see it, this prompt is essentially an "executable script". In your view, should all prompts be analyzed and possibly blocked based on heuristics that flag malicious intent? Should we also prevent the LLM from simply writing an equivalent script in a programming language, even if it is never executed? How is this different from requiring all programming languages (at least from big companies with big engineering teams) to include such security checks before code is compiled?

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

#206

Post by f311a »

dakiol wrote: post #112
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…

Easier solution: you don’t need a progress bar.

It runs indefinitely to process small jobs. I could log stats somewhere, but it complicates things. Right now, it's just a single binary that automatically gets restarted in case of a problem.

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

#207

Post by f311a »

amelius wrote: post #110
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…

And do you know what type of code the LLM was trained on? How do you know its sources were not compromised?

Why do I need to know that if I'm an experienced developer and I know exactly what the code is doing? The code is trivial, just print stuff to stdout along with escape sequences to update output.

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

#208

Post by duped »

cedws wrote: post #108
exDM69 wrote: post #91

Earlier quoted context omitted.

The same applies to any Makefile, the Python script invoked by CMake or pretty much any other scriptable build system. They are all untrusted scripts you download from the internet and run on your computer. Rust build.rs is not really special in that regard. Maybe go build doesn't allow this but most other language ecosystems share the same weakness.

Yes but it's the fact that cargo can pull a massive unreviewed dependency tree and then immediately execute code from those dependencies that's the problem. If you have a repo with a Makefile you have the opportunity to review it first at least.

Do you review the 10k+ lines of generated bash in ./configure, too?

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

#209

Post by kbrkbr »

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…

But here's the catch. If you do that in a lot of places, you'll have a lot of extra code to manage.

So your suggested approach does not seem to scale well.

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

#210

Post by evertheylen »

eyberg wrote: post #191
evertheylen wrote: post #153

Earlier quoted context omitted.

If you are on Linux, I'm writing a little tool to securely isolate projects from eachother with podman: https://github.com/evertheylen/probox . The UX is an important aspect which I've spent quite some time on. I use it all the time, but I'm still looking for people to review its security.

Containers should not be used as a security mechanism.

I agree with you that VMs would provide better isolation. But I do think containers (or other kernel techniques like SELinux) can still provide quite decent isolation with a very limited performance/ease-of-use cost. Much better than nothing I'd say?
Post reply on HN