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

191–200 of 460 posts

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

#191

Post by eyberg »

evertheylen wrote: post #153
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.

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.

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

#192

Post by ec109685 »

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.

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

#193

Post by [deleted] »

bagels wrote: post #84
jim201 wrote: post #50

Pardon my ignorance, but isn’t code signing designed to stop attacks exactly like this? Even if an npm token was compromised, I’m really surprised there was no other code signing feature in play to prevent these publish events.

Code signing just says that the code was blessed by someone's certificate who at one time showed an id to someone else. Nothing to do with whether the content being signed is malicious (at least on some platforms).

[deleted]

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

#194

Post by anthk »

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.

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

#195

Post by chasd00 »

BobbyTables2 wrote: post #78
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…

Fully agree. So many people are so drunk on the kool aid, I often wonder if I’m the weirdo for not wanting dozens of third party libraries just to build a simple HTTP client for a simple internal REST api. (No I don’t want tokio, Unicode, multipart forms, SSL, web sockets, …). At least Rust has “features”. With pip and such, avoiding the kitchen sink is not an option. I also find anything not extensively used has bug…

For this specific case an llm may be a good option. You know what you want and could do it yourself but who wants to type it all out? An llm could generate an http client from the socket level on up and it would be straightforward to verify. "Create an http client in $language with basic support for GET and POST requests and outputs the response to STDOUT without any third party libraries. after processing command line arguments the first step should be opening a TCP socket". That should get you pretty far.

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

#196

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…

The "Admin" of QubesOS (dom0) is in its own VM, and it doesn't have Internet access. Nothing you download from a browser in another VM can touch dom0 without a VM break. Each VM has its own file system. Even if you wanted to copy a downloaded file to dom0, Qubes makes you jump through hoops to do it.

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

#197

Post by jim201 »

tiagod wrote: post #143
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…

Or use pnpm. The latest versions have all dependency lifecycle scripts ignored by default. You must whitelist each package.

This is the way. It’s a pain to manually disable the checks, but certainly better than becoming victim to an attack like this.

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

#198

Post by sfink »

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 think something like cargo vet is the way forward: https://mozilla.github.io/cargo-vet/

Yes, it's a ton of overhead, and an equivalent will be needed for every language ecosystem.

The internet was great too, before it became too monetizable. So was email -- I have fond memories of cold-emailing random professors about their papers or whatever, and getting detailed responses back. Spam killed that one. Dependency chains are the latest victim of human nature. This is why we can't have nice things.

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

#200

Post by norskeld »

chrisweekly wrote: post #160
tiagod wrote: post #143

Earlier quoted context omitted.

Or use pnpm. The latest versions have all dependency lifecycle scripts ignored by default. You must whitelist each package.

pnpm is not only more secure, it's also faster, more efficient wrt disk usage, and more deterministic by design.

It also has catalogs feature for defining versions or version ranges as reusable constants that you can reference in workspace packages. It was almost the only reason (besides speed) I switched a year ago from npm and never looked back.
Post reply on HN