[Spivak]

> could similarly use your existing sudo ticket

Not with most default sudo configurations. Your sudo ticket exists outside your control as a regular user and, by default, is bound to your tty. An attacker controlling another terminal can't convince sudo to execute commands with your ticket.

> manipulate the memory of your terminal emulator

On some distros this might work but you can absolutely flip a switch to disallow processes running as the same user to access each-other's memory. On secure systems this causes devs a lot of annoyance since they cant attach a debugger.

[jolmg]

> On secure systems this causes devs a lot of annoyance since they cant attach a debugger.

You can still attach a debugger on a newly created process, but if you want to attach to an already running process, you just need sudo. It's not really annoying.

[87zuhjkas]

> An attacker controlling another terminal

How about controlling not another, but the same root terminal via send keys without tmux with another xorg terminal window?

[jchw]

Wayland fixes that and is rapidly phasing out Xorg. It is long understood that X is not secure in this kind of scenario, it is NOT long understood that tmux isn’t (Or at least, I certainly have never heard this.)

[buildzr]

That threat model essentially prohibits "tmux attach", which allows an attacker running as your user to connect to your terminal session, so I don't think it's a particularly useful threat model here. That's basically exactly what we signed up for by using tmux.

[jchw]

This is definitely a useful threat model because people are running tmux on servers and almost certainly do not realize that this can happen.

You do appear to be correct that it's exploitable via other, also trivial, means. That does not make the situation any less bad.

[buildzr]

Running on a server doesn't change anything, you'd need to be running on a server where you routinely give people who shouldn't have root access, access to an account with sudo privileges with a password. And be relying on your attacker to not say, simply put aliases into your shell, replace your shell, modify your path, add an LD_PRELOAD, ptrace your processes, etc.

That should be absolutely no one.