[jbroman]

Something running with your privileges could similarly use your existing sudo ticket, or manipulate the memory of your terminal emulator, or modify your shell to grab your credentials the next time you authenticate (and pass those to sudo), etc.

This isn't tmux's fault; this is fundamentally the sort of thing that's possible under the security model of modern Linux desktops.

[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]

This attack presents a way to reuse a sudo ticket over tmux. If you aren’t in the same TTY as your malicious code there should be no way to reuse a sudo ticket.

The memory modification one sounds truly not possible. In Windows it is possible via OpenProcess and WriteProcessMemory to modify other process memory under some circumstances, but I do not think the same thing is generally possible under Linux (because in most distros ptrace has been mostly locked down for a few years now)

[joshklein]

It’s worth pointing out that tmux is part of the OpenBSD project, where this would be mitigated by the replacement of sudo with doas.

[Fnoord]

> Do you mean this https://github.com/tmux/tmux? That is the source for the portable version of tmux, wrapping the native kqueue version developed for OpenBSD with libevent.

Tmux is part of the OpenBSD base system.

Tmux is not an officially developed program by the OpenBSD community.

It was imported June 1 2009.

Here is Theo de Raadt's post:

> By Theo de Raadt () on 2009-07-07 04:37

> The most impressive thing about tmux, in my view, is how frustrating the code audit was. In 2 hours, I found only one or two nits that had very minor security consequences.

> It was not accepted into the tree based on license alone. It is high quality code.

[1] https://en.wikipedia.org/wiki/OpenBSD#Subprojects

[2] https://undeadly.org/cgi?action=article&sid=20090707041154

[zokier]

I don't see how doas would mitigate this thing at all. It doesn't really matter how the window with root shell was originally elevated (sudo, su, doas etc).

[athms]

tmux is NOT part of the OpenBSD project, it is independently developed.