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?
Conceivably couldn’t a post install script be used for the malicious dependency to install its own instance of Claude code (or similar tool)? In which case you couldn’t really separate your dev environment from a hostile LLM.
Yes, though the attackers would have to pay for an account. In this case, it’s using a pre-installed, pre-authorized tool, using your own credits to hack you
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…
From the perspective of the software vendor, it may be a semi-regular occurrence that they learn that users are being actively harmed by a software vulnerability exploited in-the-wild. So that's an argument that developers have a moral obligation to maintain the ability to push updates their users without delay.
Waiting for the user to click "Check for updates..." is effectively pushing this responsibility onto the users, the vast majority of whom lack the information and expertise needed to make an informed choice about the risk.
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…
> 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.
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.
Google did a good job with securing files on Android.
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 run all npm based tools inside Docker with no access beyond the current directory.
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.
Not "instead", it's "in addition to". Your classical defense-in-depth.
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
I've been preaching this since ~2014 and had little luck getting people on board unless I have full control over a particular team (which is rare). The need to avoid "reinventing the wheel" seems so strong to so many.
I'm afraid that open source software supply chain attacks could be much more prevalent than what we are currently aware of. There is a significant market for zero-day exploits, with organizations like the NSA having teams dedicated to collecting and weaponizing them. But finding and exploiting an unintentional zero-day vulnerability is way more difficult than adding an intentional exploitable bug or backdoor to some…
Every time one of these comes up, I have similar thoughts. A threat actor is in the position to pull off a large-scale supply chain compromise, and the best thing you can think of to do with that is also the thing that will guarantee you are discovered immediately? Mine crypto on the damn CPU, or publicly post the victim's credentials to their own GitHub account? On one hand, I cannot accept that the actors that we s…
I like this aspect of cryptocurrency, in that it creates an incentive for attackers to research and burn 0-days for a lesser harm like coin mining.
> My gut tells me that these attacks must be happening in more subtle ways from time to time.
Dual_EC_DRBG plus TLS Extended Random come to mind.
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…
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.
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…
Remember the pre package manager days was ossified, archaic, insecure installations because self managing dependencies is hard, and people didn't keep them up to date. You need to get your deps from somewhere, so in the pre-package manager days you still just downloaded it from somewhere - a vendor's web site, or sourceforge, or whatever, and probably didn't audit it, and hoped it was secure. It's still work to keep things up to date and audited, but less work at least.