Live data from Hacker News

tmux Privilege Escalation

markdownbin.com

11–20 of 40 posts

Re: tmux Privilege Escalation

#11
post #6

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.

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.

Re: tmux Privilege Escalation

#12
post #6

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.

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

Re: tmux Privilege Escalation

#13
post #6

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.

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.

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

Re: tmux Privilege Escalation

#14
post #6

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.

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.

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

Re: tmux Privilege Escalation

#17
post #12
post #6

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.

> 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 disall…

> 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?

Re: tmux Privilege Escalation

#18
post #15

TL;DR Do not run untrusted nor not-fully-understood software as a user which is allowed to do anything, or maybe ever.

Isolation is always key. Remember, sudo can also be used to de-escalate priviledges to a different user account where it's harm is more limited.

Or better, if you wanna run malware for fun, run a VM with an isolated network connection that only routes out to the world via a separate VM that pipes all traffic over a crappy commercial VPN service or Tor. That way if you piss off any script kiddies they can't DDoS you.

Re: tmux Privilege Escalation

#19
post #6

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.

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.

> 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

Re: tmux Privilege Escalation

#20
post #12

Earlier quoted context omitted.

> 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 disall…

> 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?

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.)
Post reply on HN