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

361–370 of 460 posts

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

#361

Post by sieabahlpark »

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…

[dead]

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

#362

Post by lrvick »

Reminder that just because you got code from an internet rando making a new release, instead of from a peer, does not mean you get to skip code review. It blows my mind that any companies allow copying newly published code off the internet and putting it on privileged systems without review.

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

#363

Post by oulipo2 »

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…

Does it work the same for pnpm ?

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

#364

Post by oulipo2 »

homebrewer wrote: post #211
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 also use bubblewrap to isolate npm/pnpm/yarn (and everything started by them) from the rest of the system. Let's say all your source code resides in ~/code; put this somewhere in the beginning of your $PATH and name it `npm`; create symlinks/hardlinks to it for other package managers: #!/usr/bin/bash bin=$(basename "$0") exec bwrap \ --bind ~/.cache/nodejs ~/.cache \ --bind ~/code ~/code \ --dev /dev \ --die-with-p…

Will this work on osX? and for pnpm?

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

#365

Post by oulipo2 »

theamk wrote: post #356
conception wrote: post #343

Earlier quoted context omitted.

It means that someone just has to compromise bubblewrap instead of the other vectors.

Not "instead", it's "in addition to". Your classical defense-in-depth.

No, "instead". If they compromise bubblewrap to send out your files, and you run bubblewrap anyway for any reason, you're still compromised.

But obviously you can probably safely pin bubblewrap to a given version, and you don't need to "install packages through it", which is the main weakness of package managers

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

#366

Post by oulipo2 »

lrvick wrote: post #359
halflife wrote: post #181

Earlier quoted context omitted.

This sucks for libraries that download native binaries in their install script. There are quite a few.

Downloading binaries as part of an installation of a scripting language library should always be assumed to be malicious. Everything must be provided as source code and any compilation must happen locally.

Sure, but then you need to have a way to whitelist

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

#367

Post by fluoridation »

cedws wrote: post #65
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…

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.

Does it really matter, though? Presumably if you're building something is so you can run it. Who cares if the build script is itself going to execute code if the final product that you're going to execute?

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

#368

Post by haswell »

conception wrote: post #343
homebrewer wrote: post #317

Earlier quoted context omitted.

Not sure what this means. bubblewrap is as free as it gets, it's just a thin wrapper around the same kernel mechanisms used for containers, except that it uses your existing filesystems instead of creating a separate "chroot" from an OCI image (or something like it). The only thing it does is hiding most of your system from the stuff that runs under it, whitelisting specific paths, and optionally making them readonly…

It means that someone just has to compromise bubblewrap instead of the other vectors.

While this may be true, this is still a major improvement, no?

i.e. it seems far more likely that a rapidly evolving hot new project will be targeted vs. something more stable and explicitly security focused like bubblewrap.

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

#369

Post by sneak »

kasey_junk wrote: post #88
sneak wrote: post #62

Earlier quoted context omitted.

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

Ok, but that’s true of _any_ program you install so isn’t interesting. I don’t think the current agent tool call permission model is _right_ but it exists, so saying by default it will freely run those calls is less true of agents than other programs you might run.

Not all programs misbehave in this way. Signal desktop lets you turn off this vulnerability, and of course iOS apps and normal macOS apps are not allowed to self-modify, as it breaks their signature.

https://github.com/signalapp/Signal-Desktop/issues/4578

https://github.com/syncthing/syncthing-macos/issues/122

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

#370

Post by david_allison »

BobbyTables2 wrote: post #69

ELI5, how was the malicious PR approved and merged? Are they using AI for automated code review too?

The workflows were set up to execute with a read/write `GITHUB_TOKEN` for `nx` when a PR was created/edited (no approval necessary).

See the security warnings on `pull_request_target`

https://docs.github.com/en/actions/reference/workflows-and-a...

https://securitylab.github.com/resources/github-actions-prev...

Post reply on HN