upvote
Not that it doesn’t have issues, but I’m not sure why you’d choose tmux of all things. It runs as a user and has no privileges to escalate. It was written for and is part of OpenBSD and follows their security hardening practices.

(There actually was one privilege escalation bug in tmux, but it actually seems like a distro packaging error. The distro setgid the executable so the resulting shell inherited the additional group. This didn’t require any exploit, that’s just how child process inheritance works.)

reply
as I mentioned in another sibling, its because it's a very common denominator in high value targets. I didn't know its legacy was from OpenBSD but I really doubt that that helps it much in this scenario, when I say LPE I'm not talking about user to root elevation, I'm talking parsed text/control sequences to arb code execution in the user context. These will slip past llm classifiers as safe and I'm fairly sure that they are extremely common in codebases like tmux, despite them having strong security posture its just a threat that was previously a bit outlandish and not accounted for.

persisted malicious code running in your tmux process that you don't know about is probably not where you want to be, for obvious reasons.

reply
Agent harnesses aren’t going to output ansi escape sequences verbatim to the terminal.

If you wanted to booby trap a repository then you’re far better off with a prompt injection attack.

reply
deleted
reply
deleted
reply
I don’t think tmux is the most worthwhile target because you’d need the user to either execute code locally (thus negating any point in targeting tmux) or rely on the user curl or cat some compromised document (in which case you’re better off targeting curl or cat).
reply
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.
reply
That 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.

reply
the fact that you can vibe code a harness to look for bugs in a famously complicated C codebase is intern level stuff and hardly news

It seems like this would have been pure fantasy not that long ago though. So why isn’t it noteworthy again? I don’t really follow what you’re complaining about.

reply
deleted
reply