3 ms·
the point is tmux is being used by many developers working in high value targets to automate long running unsupervised agent tasks. you don't need the user to e
by justonenote 1mo ago
the point is tmux is being used by many developers working in high value targets to automate long running unsupervised agent tasks. you don't need the user to execute code, you need _their agent_ to stumble on the wrong search result or github repo and it wont be noticed for hours that they loaded a persistent threat into your environment.
- hnlmorg 1mo agoThat seems even harder to do because an agent wouldnt be output text verbatim, which means you cant make use of a rendering bug (eg parsing escape codes). So you’re back to depending on the agent to execute code locally. at which point you’ve already compromised the system so don’t need a tmux bug. I’ve spent a lot of time in tmux. Including writing a frontend for it. So I’m probably more familiar than most. And I hear a lot of people say tmux (specifically) is a vulnerability because it’s written in C. But I struggle to see how it’s any more of a vulnerability than (for example) coreutils. Or any other piece of software for that matter.
- justonenote 23d agoappreciate the input from someone who works in the codebase, but ok maybe tmux is openbsd secure, but it still has quirks and combined with agent harnesses not understanding them its a large attack surface Imo, what may be in inconsequential rendering artefact in tmux or inconsequential behavior on user input like scroll back or pane focus or whatever convinced with bad parsing from "acme client" program cant result in RCE, Id be more surprised if this _wasnt_ the case and tmux+acme clents have no bugs that can be chained, no matter how battle tested tmux itself is.