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

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.

[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

[wahern]

FWIW, libevent was originally written by an OpenBSD contributor who wished to write portable programs which could make use of kqueue on BSD and select/poll elsewhere. At the time Linux didn't yet have epoll.

In any event, tmux on OpenBSD also uses libevent as libevent is, naturally, part of the base system. libevent as most people know it was originally a portability fork of OpenBSD's version, similar to the portable versions of tmux, OpenSSH, etc, though unlike those projects core libevent development eventually switched to the portable version and OpenBSD stopped (AFAICT) backporting changes wholesale.

[joshklein]

As best I can tell, tmux is developed primarily by Nicholas Marriott for OpenBSD and made portable with libevent. The original paper uses OpenBSD, and here[1] he says: “I preferred to work on it in base: I felt tmux would be improved by being part of OpenBSD.”

[1] https://www.undeadly.org/cgi?action=article&sid=200907121904...

[athms]

The author developed tmux on OpenBSD because that is what he used, but it was never part of the OpenBSD Project. It was a port prior to being included in the base install. This is no different that how FreeBSD includes software in its base install, yet this doesn't make the code part of the FreeBSD Project.

The tmux GitHub repo is the reference implementation. As an example, OpenSSH is developed internally to OpenBSD and the project creates a separate portable version. tmux is the opposite, it is developed independently of OpenBSD and the project maintains its own implementation.

[abcdef123xyz]

You are incorrect, tmux is part of OpenBSD and the OpenBSD CVS tree is the main repository.

Edit: because there is occasionally confusion on this point I recently documented it here: https://github.com/tmux/tmux/wiki/Contributing

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