1. 12
  1.  

  2. 31

    Woah, hold on. I just found another exploit. If root logs in on VT2, and you’re logged in on VT1, and you press ctrl-alt-f2, you become root.

    For serious though, if the attacker can run send-keys… they can run tmux at and not only send keys, but read responses.

    1. 5

      A water is wet security report. Awesome.

      1. 10

        To my knowledge tmux doesn’t advertise/support privilege-separation by pane, so I’m not sure how big a deal this is in practice (I’m fairly certain that if you start a tmux session as user you cannot send commands to another tmux sesssion which was started as root, for example).

        1. 4

          Agreed, I’m not seeing the vulnerability here. At least, not with tmux

          1. 0

            I believe the issue is that, given one single tmux session with multiple windows/panes, you can send-keys to any pane. The user could have used su or sudo to open and keep a root shell in one of the panes. So, the send-keys is done as non-root, but the keystrokes/characters go into a root shell.

            As far as I know, you can’t send from one shell session to another (as the same user) with ssh or common shells like bash or zsh.

            1. 3

              I think you are confusing shells, remote connect protocols and terminal multiplexers. Tmux is a terminal multiplexer, its job is to allow users with access to the tmux server to access multiple shells or programs on a single display. This is also “scriptable” using the provided tmux commands. The pseudo terminals that are accessible under tmux are under the user’s control; the user is also deciding what programs are running in these pseudo terminals (by decision, I mean he actually has to authenticate willingly as root, using su).

              I really like tedu’s comment above. The analogy is quite simple to explain: if you have multiple VTs, in each VT a different user being logged on. You now have a monitor and a keyboard attached to this system. Does this mean the keyboard is vulnerable to privilege escalation, as you can now switch consoles with Ctrl+Alt+Fn ?

              Here’s another analogy: you have a web browser logged-on your webmail. Does this mean that the shell spawning the browser is vulnerable to privilege escalation? Obviously, someone with shell access to that system, under your username, can read the browser cookies and use them to access your webmail account.

              1. 4

                I really like tedu’s comment above. The analogy is quite simple to explain: if you have multiple VTs, in each VT a different user being logged on. You now have a monitor and a keyboard attached to this system. Does this mean the keyboard is vulnerable to privilege escalation, as you can now switch consoles with Ctrl+Alt+Fn ?

                The thing that I think could actually trip people up is that VT’s are routinely used to run different things at different privilege levels (especially while debugging system issues). For example, say you log on as root on VT1, and a throwaway user on VT2 to try something out. On any Unix I know of, it wouldn’t be necessary to log out of VT1 before running untrusted code on VT2, because a script run as an untrusted user on VT2 shouldn’t be able to send keystrokes to the root shell on VT1, even though you, the operator, could switch to VT1 and type keystrokes there. (There are also programmatic ways to send stuff to other terminals, but on a typical Unix, the permissions to do that require running as root.)

                People sometimes treat it as a replacement for VTs, which might be surprising if code can potentially execute at the highest privilege level available in any pane of the tmux session, and/or as the owner of the tmux process itself. So it generally shouldn’t be used for sysadmin-type tasks where you might sometimes drop privileges to an untrusted user before running things. (Maybe nowadays those should all be automated and/or explicitly sandboxed anyway, but it’s not uncommon with traditional Unix system administration to sometimes have such tasks.)

                edit: This is wrong, see below…

                1. 7

                  I think this reflects a misunderstanding of what’s happening. tmux does not allow a program from one pane to send keystrokes to another pane. tmux allows the user who ran tmux to send keystrokes to their tmux session.

                  If user alice runs tmux, and then uses su to switch to bob in one session, bob cannot send keystrokes to any other alice session. alice, however, can send keystrokes to the session with a bob login, because alice still owns the terminal it’s running in.

                  1. 2

                    I think this reflects a misunderstanding of what’s happening. tmux does not allow a program from one pane to send keystrokes to another pane.

                    Yes, if the above is truly not allowed, then I admit I have misunderstood the original post. However, I just tested the following script, after using su (including manual password entry) to set up pane 1 to have a root shell. It does indeed type into the root shell in pane 1, including pressing Enter to execute the command.

                    #!/bin/sh
                    tmux send-keys -t 1 "echo 'hello'"
                    tmux send-keys -t 1 "Enter"
                    

                    I admire the knowledge level and logic skills of those for whom this is unsurprising, or who downplay it as equivalent to some other already-known and already-existing attack vector. I myself would not have conceived this use of tmux.

                    1. 1

                      Ah, right, sorry, I think I did misunderstand. So the case where you drop privileges in one tmux pane to a user who doesn’t own the tmux session is still safe-ish, which I thought this link had claimed wasn’t the case.

                    2. 1

                      It is possible to send keystrokes from VT1 to VT2, by using the uinput kernel module. This is exactly the behaviour happening in tmux. If the user is able to access /dev/uinput (or the tmux session), then it can send any keystroke to any VT (or any tmux window/pane).

                      Edit: I do agree that the typical Linux does not have this module loaded the device accessible by default. Neither is the tmux session of a single user.

              2. 1

                Just to satisfy my curiosity, I logged into my ubuntu machine and started a tmux session as root. Then I started a session as my regular user. As expected, the sessions aren’t able to see one another.

                1. 1

                  The problem scenario is different than that:

                  Start one session as a non-root user. Open two windows/panes. su or sudo to become root in one pane. Then you can send-keys from the non-root pane to the root pane. send-keys can be executed from the CLI (that is, can be done from shell scripts or programs executing shell commands).

                  1. 1

                    I understand that, it just doesn’t personally bother me all that much. It doesn’t seem conceptually different than running a sudo command, and then running some shell script which then attempts to do something with sudo permissions. It is worth being aware of, but seems more like an expected (if edge-case) property of how tmux works rather than some security hole. That’s just my personal view though.

                    1. 1

                      Well, for me, the key difference is passwordless vs. not.

                      1. 1

                        But that would be the same with the sudo case too, right? I don’t know what the sudo password expiry time limit is, but on my system if I issue a sudo command, there is a window of time in which a subsequent sudo command will not require a pw (and if it comes from a script etc issued by my user in that session, there is no difference)

                        It will be interesting to see what if anything tmux changes about this - I’m not sure, if that were my project, what I would do. Even reading the comments here, I’m finding my opinion sort of still in formation.

                        1. 1

                          Perhaps one option is to offer two binaries, one with send-keys, one without. I’ve never used that feature, and probably wouldn’t, even now that I’ve found out about it. A similar pair of options could be offered for source builders via ./configure switches, perhaps.

              3. 4

                This is super-misleading.

                Of course, if you su to root in a tmux, then you can send keys from another of your unprivileged panes.

                Even if tmux didn’t have the keystroke sending functionality, you could just attach to the session containing the root shell and send keys that way!

                TL;DR: If you log in as root, you can run commands as root! Shocker!

                1. 2

                  I don’t understand. How can you send keys [from a script or program] without send-keys, and without typing on the [victim’s] keyboard?

                  1. 2

                    If the user ‘jack’ starts a tmux session called S1:

                    tmux new -sS1
                    

                    Then he uses sudo and the tmux session now contains a root shell.

                    The linked article now points out that if someone with access to jack’s account opens another tmux session S2, they can send keys to the session S1 and have root commands executed.

                    This of course assumes that the “attacker” has access to jacks account in the first place in order to create S2. Both sessions must be owned by the same user so that the sessions use the same tmux socket for communication (and I’m assuming the socket permissions have not been fiddled).

                    But if you have access to jack’s account to create S2, then you can also just do:

                    tmux a -tS1
                    

                    and see the root shell in S1 anyway. So, what’s the big deal?

                    All we really learn is that you shouldn’t leave root shells hanging around, but that’s standard practice.

                    1. 2

                      I think what the author was trying to point out is that you could send keys to the root shell without having enough access to jack’s account that you could type (in real time) arbitrary shell commands to the root shell. I think the/a scenario would be the malicious actor getting the victim to run a script or program (which the actor created).

                      1. 1

                        I think what the author was trying to point out is that you could send keys to the root shell without having enough access to jack’s account that you could type (in real time) arbitrary shell commands to the root shell

                        That’s not what I take away from the article:

                        su # login as root
                        Now go back to the other tmux pane (where you are logged in as user). Now run the following script…

                        So there’s the explicit assumption that you already have used su (or similar) to get root access, and you already have an unprivileged shell.

                        I think the/a scenario would be the malicious actor getting the victim to run a script or program (which the actor created).

                        Well yes, tmux cannot protect users from themselves. By the same logic, all shells are arbitrary code execution vulnerabilities ;)

                        1. 1

                          By the same logic, all shells are arbitrary code execution vulnerabilities

                          But can you run from a non-root shell commands as root without knowing the root password?

                          1. 1

                            I take your point, but isn’t this also not unique to tmux? I think you could pull the same trick using /dev/tty* device nodes if you logged in as jack and used su?

                            1. 1

                              I think so. Others have pointed out similar already-existing concerns with TTYs.

                              1. 3

                                Having thought about your point some more, I think you are on to something.

                                Here’s a more compelling scenario:

                                Suppose some rogue code entered a software package, which subsequently was imported into an OS package manager, or a programming language package manager (pip, npm, …). The untrusted code could be scanning for tmux sessions or ttys which were initiated by unprivileged users, but which have escalated privileges through sudo/su/doas/…

                                In another scenario, perhaps untrusted Javascript code from the Internet could have broken its browser sandbox and employed the same kind of scanning.

                                So actually, @Pistos, you’ve changed my mind! Hat off to you sir!

                                My next question: how do you mitigate it? Only ever log in as root from the system console? Then the tty device node is presumably owned by root? Make ttys and tmux “root aware” (ugh)?

                                1. 2

                                  Well, what I do is start tmux directly as root for root operations. I don’t use sudo for one-off root command execution. I’m thinking this should keep me safe from this particular vulnerability.

                                  1. 2

                                    Yeah @Pistos may be changing my mind here also. If you were the tmux maintainer, what would you do about this? I use tmux daily (can’t imagine living without it) and genuinely am not sure what a reasonable solution to this would be. Check privilege/user levels between panes? But what if you use tmux to ssh to multiple nodes, and send-keys to issue simultaneous identical commands across nodes?

                                    1. 3

                                      I’m still not convinced this is a tmux-only issue by the way. See my comment above about tty device nodes possibly having the same problem (not had a chance to test it yet).

                  2. 3

                    This isn’t any fundamentally different than issuing su or similar from an Xterm and sending keystrokes to it. (Interestingly, Windows does mitigate that particular case - if there’s a privileged application’s window, you can’t send messages to it from a lower privileged window.)

                    1. 1

                      interesting. is it possible to access the tmux server remotely by default? or do you need to go over some kind of transport medium like SSH?

                      1. 2

                        The server is on a local unix domain socket. You have to SSH in as the same user to get access to this user’s session.

                        1. 1

                          I think one attack vector is this: Suppose malicious code is installed, but can only execute as the non-root user. With this, the malicious code can send arbitrary shell commands to tmux panes, one of which could be running an escalated shell. I believe tmux allows running commands via shell. Meaning to say, they don’t need to be run via the interactive “:” prompt within tmux’s UI.

                          If your user can already execute priveleged shell commands without password (via sudo), then you’re pretty wide open as it is, but this tmux issue shows how even password-requiring escalation (such as with su) can be enjoyed without password.

                          1. 1

                            Afaik you have to use ssh. Then you could do tmux attach

                            There is a service called tmate which exposes a (new) tmux session remotely via ssh. Presumably it is also vulnerable to this.