Tiocsti Tioclinux Security Problems

There are long known issues with the IOCTL commands TIOCSTI and TIOCLINUX on terminal devices.

It can at least be traced back to this post (alternative link) on the Unix “Security Mailing List” from May 1985(!!), by John Bruner <ihnp4!dual!mordor!jbd>:

The TIOCSTI ioctl (a.k.a. the "force" command) is one of the worst
security holes in 4.XBSD.  As far as I can tell, it was implemented
so that the "To:", "Subject:", "Cc:", etc. lines in Berkeley Mail
could be input-edited by the kernel.

In short, the TIOCSTI IOCTL command emulates keypresses (“stores characters in the terminal input buffer”). This feature has been abused in multiple exploits where programs ran at a different level of privilege than the surrounding shell, but were able to push commands into the terminal, which would then be interpreted by the surrounding shell when the programs exits.

TTY device /bin/sh su -T -c program alice program reads commands   from input buffer     can write to   input buffer  root  alice  user  keypresses  input buffer

While other UNIX vendors have largely addressed this problem, it was left unaddressed in Linux for a long time. Worse, Linux also created an additional variant of the problem, where some of the subcommands of the TIOCLINUX IOCTL command would offer another way to insert characters into the terminal input buffer. (These features are only available on Linux’s text console, to support cut&paste with console mouse drivers like gpm.)

Was this really a problem?

Yes!

There is a long list of CVEs that mention TIOCSTI, affecting multiple sandboxing and privilege-changing tools: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=TIOCSTI

A workaround that does not work well for Landlock

Alan Cox, who maintained the TTY subsystem, has taken the stance in 2017 that processes with that problem should create a new pseudoterminal and use that:

The proper way to handle those cases is to create a pty/tty pair and use that. Your patch is pure snake oil and if anything implies safety that doesn’t exist.

While pseudo terminals fix the TIOCSTI problem, they are difficult to implement for user space programs, because a special process needs to be kept around to shovel data between the surrounding terminal and the new pseudo terminal.

The pseudo terminal approach has been successfully used by su (with the --pty flag) and sudo (the man pages of both programs talk about it). However, not all programs with the same problems were happy to go through the additional effort of creating pseudo terminals (example in OpenDoas).

In LandlockLsm, where the goal is that processes self-sandbox themselves, it might not be justifiable to keep a PTY-handling sidecar process alive, and it would have required significantly more work for a large number of programs to use Landlock correctly.

I have previously summarized some other options on the LSM list and discussed there why they don’t work for LandlockLsm.

The fix

After the fix

The most recent CVE mentioning TIOCSTI is also confirming that the fixes works:

please (aka pleaser) through 0.5.4 allows privilege escalation through the TIOCSTI and/or TIOCLINUX ioctl. (If both TIOCSTI and TIOCLINUX are disabled, this cannot be exploited.)

References