4 ms·

Something running with your privileges could similarly use your existing sudo ticket, or manipulate the memory of your terminal emulator, or modify your shell t

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.

joshklein 7y ago
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.
- athms 7y ago
  tmux is NOT part of the OpenBSD project, it is independently developed.
  - deleted 7y ago
    [deleted]
- zokier 7y ago
  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).
  - deleted 7y ago
    [deleted]
- Fnoord 7y ago
  > Do you mean this https://github.com/tmux/tmux 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 https://en.wikipedia.org/wiki/OpenBSD#Subprojects [2] https://undeadly.org/cgi?action=article&sid=20090707041154 https://undeadly.org/cgi?action=article&sid=20090707041154
  - joshklein 7y ago
    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=20090712190402 https://www.undeadly.org/cgi?action=article&sid=200907121904...
    - athms 7y ago
      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 7y ago
        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 https://github.com/tmux/tmux/wiki/Contributing
  - wahern 7y ago
    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.
Spivak 7y ago
> 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.
- 87zuhjkas 7y ago
  > 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 7y ago
    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 7y ago
      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 7y ago
        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.
jchw 7y ago
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 7y ago

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.

athms 7y ago
tmux is NOT part of the OpenBSD project, it is independently developed.
- deleted 7y ago
  [deleted]
zokier 7y ago
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).
- deleted 7y ago
  [deleted]
Fnoord 7y ago
> Do you mean this https://github.com/tmux/tmux 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 https://en.wikipedia.org/wiki/OpenBSD#Subprojects [2] https://undeadly.org/cgi?action=article&sid=20090707041154 https://undeadly.org/cgi?action=article&sid=20090707041154
- joshklein 7y ago
  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=20090712190402 https://www.undeadly.org/cgi?action=article&sid=200907121904...
  - athms 7y ago
    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 7y ago
      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 https://github.com/tmux/tmux/wiki/Contributing
- wahern 7y ago
  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.

Spivak 7y ago

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

87zuhjkas 7y ago
> 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 7y ago
  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 7y ago
    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 7y ago
      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.

jchw 7y ago

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)