Live data from Hacker News

1-Click RCE to steal your Moltbot data and keys

depthfirst.com

1–10 of 78 posts

Re: 1-Click RCE to steal your Moltbot data and keys

#6
I'm curious, outside of AI enthusiasts have people found value with using Clawdbot, and if so, what are they doing with it? From my perspective it seems like the people legitimately busy enough that they actually need an AI assistant are also people with enough responsibilities that they have to be very careful about letting something act on their behalf with minimal supervision. It seems like that sort of person could probably afford to hire an administrative assistant anyway (a trustworthy one), or if it's for work they probably already have one.

On the other hand, the people most inclined to hand over access to everything to this bot also strike me as people without a lot to lose? I don't want to make an unfair characterization or anything, it just strikes me that handing over the keys to your entire life/identity is a lot more palatable if you don't have much to lose anyway?

Am I missing something?

Re: 1-Click RCE to steal your Moltbot data and keys

#9
I rushed out nono.sh (the opposite of yolo!) in response to this and its already negated a few gateway attacks.

It uses kernel-level security primitives (Landlock on Linux, Seatbelt on macOS) to create sandboxes where unauthorized operations are structurally impossible. API keys are also stored in apples secure enclave (or the kernel keyring in linux) , and injected at run time and zeroized from memory after use. There is also some blocking of destructive actions (rm -rf ~/)

its as simple to run as: nono run --profile openclaw -- openclaw gateway

You can also use it to sandbox things like npm install:

nono run --allow node_modules --allow-file package.json package.lock npm install pkg

Its early in, there will be bugs! PR's welcome and all that!

https://nono.sh

Re: 1-Click RCE to steal your Moltbot data and keys

#10

The real problem is that there is nothing novel here. Variants of this type of attack were clear from the beginning.

What I would have expected is prompt injection or other methods to get the agent to do something its user doesn't want it to, not regular "classical" attacks.

At least currently, I don't think we have good ways of preventing the former, but the latter should be possible to avoid.

Post reply on HN