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.
tmux Privilege Escalation
11–20 of 40 posts
Re: tmux Privilege Escalation
#12Something 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.
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
#13Something 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
#14Something 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
#15Re: tmux Privilege Escalation
#16Re: tmux Privilege Escalation
#17Something 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…
How about controlling not another, but the same root terminal via send keys without tmux with another xorg terminal window?
Re: tmux Privilege Escalation
#18TL;DR Do not run untrusted nor not-fully-understood software as a user which is allowed to do anything, or maybe ever.
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
#19Something 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 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
#20Earlier 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?