The TIOCSTI and TIOCLINUX IOCTL commands
The release of Linux 6.7 marks the point when both the TIOCSTI
and
TIOCLINUX
IOCTL commands can finally be secured from misuse.
Both IOCTL commands operate on TTY file descriptors, TIOCSTI
on any
terminal, and TIOCLINUX
on the console device, the proper Linux text
console, which most people see only briefly at boot time.
What is the problem with these?
These IOCTL commands have been primarily used in numerous software exploits in the past, while their original purpose has not seen much use.
The way this was used in exploits in when a process was running with
different privileges than the calling process. If on top of that, the
calling process was invoked from a terminal, TIOCSTI
and TIOCLINUX
made it possible to control the surrounding terminal.
Both of these IOCTL commands permitted to let callers simulate keyboard entry to the affected terminal devices, by virtue of having a writable file descriptor for that terminal.
And this is not just theoretical…
In principle, this is working as intended, but in practice, writable
file descriptors get passed around a lot. The list of affected tools
is long, which you can see when you query for TIOCSTI
at
cve.mitre.org.
Affected products included: OpenDoas, Flatpak, Bubblewrap, Firejail,
SELinux policyutils
, GNU coreutils' chroot
, util-linux runuser
,
pkexec
, LXC, and finally also su
and sudo
. (Challenge: Name a
sandboxing or privilege change tool which is not on this list! o_O)
References:
- TIOCLINUX patch v2
- TIOCLINUX man page change
- Query for
TIOCSTI
at cve.mitre.org - FreeBSD ping bug
- Alan Cox' suggestion to use pty/tty pairs (2017)
- Other people writing about it
- https://isopenbsdsecu.re/mitigations/tiocsti/ (“This is a low-hanging hole that should be now closed in every UNIX.")