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

301–310 of 460 posts

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

#301

Post by tailspin2019 »

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…

I think you’re right. I don’t like the idea of a “building code” for software, but I do agree that as an industry we are doing quite badly here and if regulation is what is needed to stop so many terrible, terrible practices, then yeah… maybe that’s what’s needed.

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

#302

Post by echelon »

maerch wrote: post #205
echelon wrote: post #23

Earlier quoted context omitted.

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

Prompts are not just executable scripts. They are API calls to servers that are listening and that can provide dynamic responses.

These companies can staff up a team to begin countering this. It's going to be necessary going forward.

There are inexpensive, specialized models that can quickly characterize adversarial requests. It doesn't have to be perfect, just enough to assign a risk score. Say from [0, 100], or whatever normalized range you want.

A combination of online, async, and offline systems can analyze the daily flux in requests and flag accounts and query patterns that need further investigation. This can happen when diverse risk signals trigger heuristics. Once a threshold has been triggered, it can escalate to manual review, rate limiting, a notification sent to the user, or even automatic account temporary suspension.

There are plenty of clues in this attack behavior that can lead to the tracking and identification of some number of attackers, and the relevant bodies can be made aware of any positively ID'd attackers: any URLs, hostnames, domains, accounts, or wallets that are being exfiltrated to can be shut down, flagged, or cordoned off and made subject of further investigation by other companies or the authorities. Countermeasures can be deployed.

The entire system can be mathematically modeled and controlled. It can be observed, traced, and replayed as an investagorory tool and means of restitution.

This is part of a partnership with law enforcement and the broader public. Red teams, government agencies, other companies, citizen bug and vuln reporters, customers, et al. can participate once the systems are built.

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

#303

Post by andix »

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…

nx is not a random dependency. It's a multi-project management tool, package manager, build tool, and much more. It's backed by a commercial offering. A lot of serious projects use it for managing a lot of different concerns. This is not something silly like leftpad or is-even.

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

#304

Post by dvfjsdhgfv »

mirekrusin wrote: post #290
norskeld wrote: post #200

Earlier quoted context omitted.

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.

workspace protocol in monorepo is also great, we're using it a lot.

OK so it seems too good now, what are the downsides?

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

#305

Post by c-hendricks »

dvfjsdhgfv wrote: post #304
mirekrusin wrote: post #290

Earlier quoted context omitted.

workspace protocol in monorepo is also great, we're using it a lot.

OK so it seems too good now, what are the downsides?

If you relied on hoisting of transitive dependencies, you'll now have to declare that fact in a project's .npmrc

Small price to pay for all the advantages already listed.

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

#306

Post by teddyh »

coldpie wrote: post #106
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.

> If you can’t run on $current_debian, that’s very much a you problem. This is a reasonable position for most software, but definitely not all, especially when you fix a bug or add a feature in your dependent library and your Debian users (reasonably!) don't want to wait months or years for Debian to update their packages to get the benefits. This probably happens rarely for stable system software like postgres and n…

Something I have seen that recently have become much more common is the software upstream authors providing a Debian repository for the latest versions of their software, including backports for old Debian releases.

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

#307

Post by cluckindan »

freedomben wrote: post #265
cluckindan wrote: post #178

Earlier quoted context omitted.

Not exactly. A supply chain attack can be used to deliver RCE enabling payloads such as a reverse shell, but in itself, it is not considered RCE. RCE implies ability to remotely execute arbitrary code on an affected system at will.

> A supply chain attack can be used to deliver RCE enabling payloads such as a reverse shell, but in itself, it is not considered RCE. Yes, as I tried to make clear above, these are orthogonal. The supply chain attack is NOT an RCE, it's a delivery mechanism. The RCE is the execution of the attacker's code, regardless how it got there. > RCE implies ability to remotely execute arbitrary code on an affected system at…

https://www.sciencedirect.com/topics/computer-science/remote...

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

#308

Post by [deleted] »

echelon wrote: post #53
dpoloncsak wrote: post #29

Earlier quoted context omitted.

What does Google or Antropic have to do with anything here? NX was compromised. Threat actors are using this access to leverage CLI LLMs to search the computer for you. Is this any different than if they just ran a big /find? Should the AI Assistant NOT reply to the request it was given? Why shouldn't it?

> Should the AI Assistant NOT reply to the request it was given? Why shouldn't it? LLMs are not a dumb interpreter. At minimum, they are a client-server architecture that can be used as a control plane. But they are much more than that and can likely employ advanced detection and classification heuristics. The vendors have the capability of (1) stopping this in its tracks, (2) understanding the extent of the attack a…

[deleted]

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

#309

Post by hft »

jMyles wrote: post #173

So... who's got the hot guide on running Claude Code isolated in a project-level container of some kind? Doesn't need to be a full-blown VM, but I definitely want to be done letting it have read access to ~.

That's how I run claude code in a container having access to just a mounted volume from my dev machine: https://gist.github.com/fabiant7t/06757e67187775931b0ec6c402...

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

#310

Post by jen20 »

skydhash wrote: post #260
marcosdumay wrote: post #248

Earlier quoted context omitted.

It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries. What happens is that distro developers spend their time patching the upstream so it works with the set included on the distro. This has some arguable benefits to any user that wants to rebuild their software, at the cost of random problems added by that patching th…

> It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries. That is not what it's being asked. As a developer, you just need to provide the code and the list of requirements. And maybe some guide about how to build and run tests. You do not want to care about where I find those dependencies (Maybe I'm running you code as…

The question is whose issue tracker ends up on blast when something that Debian did causes issues in software. Often only to find that the bug has been fixed already but the distribution won't bother to update.
Post reply on HN