| ▲ | divan 6 days ago |
| So any process on my computer could just start using Claude Code for their own purposes or what? o_O |
|
| ▲ | algo_lover 6 days ago | parent | next [-] |
| Any postinstall script can add anything to your bashrc. I sometimes wonder how the modern world hasn't fallen apart yet. |
| |
| ▲ | myaccountonhn 5 days ago | parent | next [-] | | I don't think this solves the world but as a quickfix for this particular exploit I ran: sudo chattr -i $HOME/.shrc sudo chattr -i $HOME/.profile to make them immutable. I also added: alias unlock-shrc="sudo chattr -i $HOME/.shrc" alias lock-shrc="sudo chattr +i $HOME/.shrc" To my profile to make it a bit easier to lock/unlock. | |
| ▲ | bethekidyouwant 5 days ago | parent | prev [-] | | realistically, how many times has this happened in eg homebrew?
Hard to be worried tbh. |
|
|
| ▲ | mathiaspoint 6 days ago | parent | prev | next [-] |
| Even before AI the authors could have embeded shells in their software and manually done the same thing. This changes surprisingly little. |
|
| ▲ | IshKebab 6 days ago | parent | prev | next [-] |
| Yeah but so what? A process on your computer could do whatever it wants anyway. The article claims: > What's novel about using LLMs for this work is the ability to offload much of the fingerprintable code to a prompt. This is impactful because it will be harder for tools that rely almost exclusively on Claude Code and other agentic AI / LLM CLI tools to detect malware. But I don't buy it. First of all the prompt itself is still fingerprintable, and second it's not very difficult to evade fingerprinting anyway. Especially on Linux. |
|
| ▲ | echelon 6 days ago | parent | prev | next [-] |
| Yes. It's a whole new attack vector. This should be a SEV0 at Google and Anthropic and they need to be all-hands in monitoring this and communicating this to the public. Their communications should be immediate and fully transparent. |
| |
| ▲ | antiloper 6 days ago | parent [-] | | It's not a SEV0 for LLM providers. If you already have code execution on some system, you've lost already, and whatever process the malware happens to start next is not at fault. | | |
|
|
| ▲ | m-hodges 6 days ago | parent | prev | next [-] |
| While this feels obvious once its pointed out, I don't think many people have considered it or its implications. |
|
| ▲ | 42lux 6 days ago | parent | prev [-] |
| Edit: Was not supposed to create a flamewar about semantics... |
| |
| ▲ | saberience 5 days ago | parent | next [-] | | If that's your definition then most of modern software is an RCE. Mac OSX is also an RCE, so is Windows 11, Chrome etc. | | | |
| ▲ | cluckindan 6 days ago | parent | prev | next [-] | | It’s not an RCE, it is a supply chain attack. | | |
| ▲ | freedomben 6 days ago | parent [-] | | It's an RCE delivered via supply chain attack | | |
| ▲ | djent 5 days ago | parent [-] | | malware isn't remote. therefore it isn't remote code execution | | |
| ▲ | freedomben 5 days ago | parent [-] | | If you can execute code on some machine without having access to that machine, then it's RCE. Whether you gain RCE through an exploit in a bad network protocol or through tricking the user into running your code (i.e. this attack) is merely a delivery mechanism. It's still RCE | | |
| ▲ | cluckindan 5 days ago | parent [-] | | 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. | | |
| ▲ | freedomben 5 days ago | parent [-] | | > 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 will. We'll have to disagree on this one, unless one of us can cite a definition from a source we can agree on. Yes frequently RCE is something an attacker can push without requiring the user to do something, but I don't think that changes the nature of the fact that you are achieving remote code execution. Whether the user triggers the execution of your code by `npm install`ing your infected package or whether the attacker triggers it by sending an exploitative packet to a vulnerable network service isn't a big enough nuance in my opinion to make it not be RCE. From that perspective, the user had to start the vulnerable service in the first place, or even turn the computer on, so it still requires some user (not the attacker) action before it's vulnerable. | | |
|
|
|
|
| |
| ▲ | divan 6 days ago | parent | prev [-] | | Ah, I didn't know that claude code has headless mode... |
|
