5 ms·

So any process on my computer could just start using Claude Code for their own purposes or what? o_O

by divan 1y ago

m-hodges 1y ago
While this feels obvious once its pointed out, I don't think many people have considered it or its implications.
echelon 1y ago
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 1y ago
  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.
  - echelon 1y ago
    It 100% is, and I posted my rationale here [1]. I would stake my reputation on this being the appropriate stance. [1] https://news.ycombinator.com/item?id=45039442 https://news.ycombinator.com/item?id=45039442
algo_lover 1y ago
Any postinstall script can add anything to your bashrc. I sometimes wonder how the modern world hasn't fallen apart yet.
- bethekidyouwant 1y ago
  realistically, how many times has this happened in eg homebrew? Hard to be worried tbh.
- myaccountonhn 1y ago
  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.
IshKebab 1y ago
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.
mathiaspoint 1y ago
Even before AI the authors could have embeded shells in their software and manually done the same thing. This changes surprisingly little.
BoredPositron 1y ago
Edit: Was not supposed to create a flamewar about semantics...
- cluckindan 1y ago
  It’s not an RCE, it is a supply chain attack.
  - freedomben 1y ago
    It's an RCE delivered via supply chain attack
    - djent 1y ago
      malware isn't remote. therefore it isn't remote code execution
      - freedomben 1y ago
        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 1y ago
        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 1y ago
        > 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.

So any process on my computer could just start using Claude Code for their own purposes or what? o_O

by divan 1y ago

So any process on my computer could just start using Claude Code for their own purposes or what? o_O

m-hodges 1y ago

While this feels obvious once its pointed out, I don't think many people have considered it or its implications.

echelon 1y ago

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 1y ago
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.
- echelon 1y ago
  It 100% is, and I posted my rationale here [1]. I would stake my reputation on this being the appropriate stance. [1] https://news.ycombinator.com/item?id=45039442 https://news.ycombinator.com/item?id=45039442

algo_lover 1y ago

Any postinstall script can add anything to your bashrc. I sometimes wonder how the modern world hasn't fallen apart yet.

bethekidyouwant 1y ago
realistically, how many times has this happened in eg homebrew? Hard to be worried tbh.
myaccountonhn 1y ago
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.

IshKebab 1y ago

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.

mathiaspoint 1y ago

Even before AI the authors could have embeded shells in their software and manually done the same thing. This changes surprisingly little.

BoredPositron 1y ago

Edit: Was not supposed to create a flamewar about semantics...

cluckindan 1y ago
It’s not an RCE, it is a supply chain attack.
- freedomben 1y ago
  It's an RCE delivered via supply chain attack
  - djent 1y ago
    malware isn't remote. therefore it isn't remote code execution
    - freedomben 1y ago
      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 1y ago
        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 1y ago
        > 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.