Interesting they create a public repo in your GitHub to store the payload. I would have thought would be better and less obvious to just upload the payload to a server they control.
Malicious versions of Nx and some supporting plugins were published
381–390 of 460 posts
Re: Malicious versions of Nx and some supporting plugins were published
#382Claude code is by all accounts a revolutionary tool for getting useful work done on a computer. It's also: - a NodeJS app - installed by curling a shell script and piping it into bash - an LLM that's given free reign to mess with the filesystem, run commands, etc. So that's what, like 3 big glaring vectors of attack for your system right there? I would never feel comfortable running it outside of some kind of sandbox…
So what? It doesn't run by itself, you have to choose to run it. We have tons of apps with loads of permissions. The terminal can also mess with your filesystem and run commands... sure, but it doesn't open by itself and run commands itself. You have to literally run claude code and tell it to do stuff. It's not some living, breathing demon that's going to destroy your computer while you're at work. Claude Code is th…
> I couldn't give two fucks about its "vectors of attack", none of them matter if no one has unauthorized access to my computer, and if they do, Claude Code is the least of my issues.
Naive! Claude Code grants access to your computer, authorized or not. I'm not talking about Anthropic, I'm talking about the HTML documentation file you told Claude to fetch (or manually saved) that has an HTML comment with a prompt injection.
Re: Malicious versions of Nx and some supporting plugins were published
#383Earlier quoted context omitted.
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…
We're talking about Claude Code, the frontend to the online, hosted LLM inference suite, right? The auto-updater isn't where they get their usage metrics.
Re: Malicious versions of Nx and some supporting plugins were published
#384Earlier quoted context omitted.
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 li…
Sure, after all, when has vibe coding ever resulted in security issues?
You missed the easily verified part.
Re: Malicious versions of Nx and some supporting plugins were published
#385Earlier quoted context omitted.
Yes but it's the fact that cargo can pull a massive unreviewed dependency tree and then immediately execute code from those dependencies that's the problem. If you have a repo with a Makefile you have the opportunity to review it first at least.
Do you review the 10k+ lines of generated bash in ./configure, too?
./configure shouldn't be in your repo unless it's handwritten
Re: Malicious versions of Nx and some supporting plugins were published
#386Before 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…
>This is why I continue to insist there needs to be building codes for software, with inspections and fines for not following through. This attack could have been used on tens of thousands of institutions to bring down finance, power, telecommunications, hospitals, military, etc. And the scope of the attacks and their impact will only increase with AI. Clearly we are not responsible enough to write software safely and securely. So we must have a building code that forces us to do it safely and securely.
Yea, except taps on the glass
https://github.com/nrwl/nx/blob/master/LICENSE
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
We can have building code, but the onus is on the final implementer not people sharing code freely.
Re: Malicious versions of Nx and some supporting plugins were published
#387Earlier 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.
Am I getting bubblewrap somewhere other than my distro? What makes it different from any other executable that comes from there?
Re: Malicious versions of Nx and some supporting plugins were published
#388Periodic 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…
Pnpm natively lets you selectively enable it on a package basis
Re: Malicious versions of Nx and some supporting plugins were published
#389Earlier quoted context omitted.
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.
They’re moving all that to the pnpm-workspace.yaml file now
Re: Malicious versions of Nx and some supporting plugins were published
#390Earlier quoted context omitted.
> You to keep your GitHub tokens/auth in a password manager that requires you to manually authorize unsealing of the token This is a failure of the GH CLI, IMO. If you log into the GH CLI, it gets access to upload repositories, and doesn’t require frequent re-auth. Unlike AWS CLI, which expires every 18hr or something like that depending on the policy. But in either case (including with AWS CLI), it’s simply too easy…
gh cli is such a ticking time bomb. Anything can just run `gh auth token` and get a token that probably can read + write to all your work code.
These tokens never expire, and there is no way for organization administrators to get them to expire (or revoke them, only the user can do that), and they are also excluded from some audit logs. This applies not just to gh cli, but also several other first party apps.
See this page for more details: https://docs.github.com/en/apps/using-github-apps/privileged...
After discussing our concerns about these tokens with our account team, we concluded the only reasonable way to enforce session lengths we're comfortable with on GitHub cloud is to require an IP allowlist with access through a VPN we control that requires SSO.
https://github.com/cli/cli/issues/5924 is a related open feature request