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

231–240 of 460 posts

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

#231

Post by stagalooo »

bethekidyouwant wrote: post #111
OJFord wrote: post #86

Earlier quoted context omitted.

It doesn't have to be a deliberate 'attack', Claude can just do something absurdly inappropriate that wasn't what you intended. You're absolutely right! I should not have `rm -rf /bin`d!

I don’t use Claude, but can it really run commands on the cli without human confirmation? Sure there may be a switch to allow this but If in that case all but the most yolo must be using it in a container?

One easy way to accidentally give Claude permission to do almost anything is to tell it that it’s allowed to run “find” without confirmation.

Claude is constantly searching through your files and approving every find command is annoying.

The problem is, find has a --exec flag that lets it run arbitrary bash commands. So now Claude can basically do anything it wants.

I have really been enjoying Claude in a container in yolo mode though. Seems like the main risk I am taking is data exfiltration since it will has unfettered access to the internet.

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

#232

Post by eyberg »

anthk wrote: post #194
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.

Learn to use bubblewrap with small chroot.

Bubblewrap has refused to fix known security issues in its codebase and shouldn't be used.

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

#233

Post by skydhash »

imiric wrote: post #228
skydhash wrote: post #74

Earlier quoted context omitted.

Vendoring is nice. Using the system version is nicer. If you can’t run on $current_debian, that’s very much a you problem. If postgres and nginx can do it, you can too.

That is an impossible task in practice for most developers. Many distros, and Debian in particular, apply extensive patches to upstream packages. Asking a developer to depend on every possible variation of such packages, across many distros, is a tall order. Postgres and Nginx might be able to do it, but those are established projects with large teams behind them and plenty of leverage. They might even be able to inf…

You do not depends on a package, you depends on its API. Implementation details shouldn't matter if behavior stays the same. Why do you care if the distro reimplemented ffmpeg or libcurl, or use an alternative version built with musl? Either the library is there or it's not. Or the minimum version you want is there or it's not. You've already provided the code and the requirement list, it's up to the distro maintainer or the user to meet them. If the latter patch the code, why do you care that much?

And if a library have a feature flags, check them before using the part that is gated.

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

#234

Post by skydhash »

rootnod3 wrote: post #96
skydhash wrote: post #74

Earlier quoted context omitted.

Vendoring is nice. Using the system version is nicer. If you can’t run on $current_debian, that’s very much a you problem. If postgres and nginx can do it, you can too.

But that would lock me in to say whatever $debian provides. And some dependencies only exist as source because they are not packaged for $distribution. Of course, if possible, just saying "hey, I need these dependencies from the system" is nicer, but also not error-free. If a system suddenly uses an older or newer version of a dependency, you might also run into trouble. In either case, you run into either an a) trus…

> If a system suddenly uses an older or newer version of a dependency, you might also run into trouble.

You won't. The user may. On his system.

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

#235

Post by hombre_fatal »

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

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

#236

Post by autoexec »

jpalawaga wrote: post #77
sneak wrote: post #60

Earlier quoted context omitted.

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 .

So we’re declaring all software with auto-updaters as RCE? That doesn’t seem like a useful distinction.

Software that automatically phoned home to check if an update is available used to be considered spyware if there wasn't a prompt at installation asking if you wanted that. The attitude was "Why should some company get my IP address and a timestamp telling them when/how often I'm online and using their software?" Some people thought that was paranoid.

We gave them an inch out of fear ("You'd better update constantly and immediately in case our shitty software has a bug that's made you vulnerable!") and today they've basically decided they can do whatever the fuck they want on our devices while also openly admitting to tracking our IPs and when/how often we use their software along with exactly what we're using it for, the hardware we're using, and countless other metrics.

Honestly, we weren't paranoid enough.

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

#238

Post by edem »

I'm not surprised at all. Nx is a mess, I migrated away a year ago after I got fed up with the constant struggle. The last straw was when I joined their Slack to ask a question (about a bug I wanted to report) and they quoted me for a $1000 retainer if I wanted to get help.

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

#239

Post by chairmansteve »

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.

One of the wisest comments I've ever seen on HN.

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

#240

Post by skydhash »

imiric wrote: post #228
skydhash wrote: post #74

Earlier quoted context omitted.

Vendoring is nice. Using the system version is nicer. If you can’t run on $current_debian, that’s very much a you problem. If postgres and nginx can do it, you can too.

That is an impossible task in practice for most developers. Many distros, and Debian in particular, apply extensive patches to upstream packages. Asking a developer to depend on every possible variation of such packages, across many distros, is a tall order. Postgres and Nginx might be able to do it, but those are established projects with large teams behind them and plenty of leverage. They might even be able to inf…

> distro package managers carrying libraries for all programming languages is an insane practice that is impossible to scale and maintain.

That's not the idea. If a software is packaged for a distro, then the distro will have the libraries needed for that software.

If you're developing a new software and wants some new library not yet packaged, I believe you can figure how to get them on your system. The thread is about the user's system, not yours. When I want to run your code, you don't have to say:

  Use flatpak; Use docker; Use 24.1.1 instead of 24.1.0; Use $THING
Post reply on HN