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

91–100 of 460 posts

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

#91

Post by exDM69 »

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.

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.

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

#92

Post by littlecranky67 »

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…

We are using NX heavily (and are not affected) in my teams in a larger insurance company. We have >10 standalone line of business apps and 25+ individual libraries in the same monorepo, managed by NX. I've toyed with other monorepo tools for these kind of complex setup in my career (lerna, rushjs, yarn workspaces) but not only did none came close, lerna is basically handed over to NX, and rushjs is unmaintained.

If you have any proposal how to properly manage the complexity of a FE monorepo with dozens of daily developers involved and heavy CI/CD/Devops integration, please post alternatives - given that security incident many people are looking.

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

#93

Post by christophilus »

mdrzn wrote: post #18

the truly chilling part is using a local llm to find secrets. it's a new form of living off the land, where the malicious logic is in the prompt, not the code. this sidesteps most static analysis. the entry point is the same old post-install problem we've never fixed, but the payload is next-gen. how do you even defend against malicious prompts?

Run Claude Code in a locked down container or VM that has no access to sensitive data, and review all of the code it commits?

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

#94

Post by chrismustcode »

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 honestly find in go it’s easier and less code to just write whatever feature you’re trying to implement than use a package a lot of the time.

Compared to typescript where it’s a package + code to use said package which always was more loc than anything comparative I have done in golang.

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

#95

Post by wat10000 »

fluoridation wrote: post #58
wat10000 wrote: post #34

Earlier quoted context omitted.

Part of the value proposition for bringing in outside libraries was: when they improve it, you get that automatically. Now the threat is: when they “improve” it, you get that automatically. left-pad should have been a major wake up call. Instead, the lesson people took away from it seems to have mostly been, “haha, look at those idiots pulling in an entire dependency for ten lines of code. I, on the other hand, am in…

The problem is less the size of a single dependency but the transitivity of adding dependencies. It used to be, library developers sought to not depend on other libraries if they could avoid it, because it meant their users had to make their build systems more complicated. It was unusual for a complete project to have a dependency graph more than two levels deep. Package managers let you easily build these gigantic d…

The size itself isn’t a problem, it’s just a rough indicator of the benefit you get. If it’s only replacing a hundred lines of code, is it really worth bringing in a dependency, and as you point out potentially many transitive dependencies, instead of writing your own? People understood this with left-pad but largely seemed unwilling to extrapolate it to somewhat larger libraries.

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

#96

Post by rootnod3 »

skydhash wrote: post #74
rootnod3 wrote: post #59

Earlier quoted context omitted.

Fully agree. That is why I vendor all my dependencies. On the common lisp side a new tool emerged a while ago for that[1]. On top of that, I try to keep the dependencies to an absolute minimum. In my current project it's 15 dependencies, including the sub-dependencies. [1]: https://github.com/fosskers/vend

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) trust problem or b) a maintenance problem. And in that scenario I tend to prefer option b), at least I know exactly whom to blame and who is in charge of fixing it: me.

Also comes down to the language I guess. Common Lisp has a tendency to use source packages anyway.

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

#97

Post by bethekidyouwant »

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…

Just use your fork until they merge your MR?

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

#98

Post by nickstinemates »

uzy777 wrote: post #87
nickstinemates wrote: post #83

While the attack vector is completely obvious when you think about it, the gumption to do it is novel. Of course this is the best way to exfiltrate data, it's on a blessed path and no one will really bat an eye. Let's see how corporate-mandated anti virus deal with this!

How can an antivirus even prevent this?

It can't

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

#99

Post by hvb2 »

christophilus wrote: post #61
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.

Is that realistic though? What you're proposing is letting go of abstractions completely.

Say you need compression, you're going to review changes in the compression code? What about encryption, a networking library, what about the language you're using itself?

That means you need to be an expert on everything you run. Which means no one will be building anything non trivial.

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

#100

Post by skydhash »

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.

That’s pretty much the definition. Auto updating is trusting the developer (Almost always a bad idea).
Post reply on HN