On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:
Having said all of that: the suid bit itself is irrelevant. It is
nothing
more than a convenient scapegoat to blame other bugs on. The same bug that's
exploitable in a suid binary will also be exploitable, exactly the same way,
in its suid-less equivalent. If you have a buffer overrun in a suid binary
as a result of carefully-crafted command-line parameters or environment,
then if you replace the suid binary with an identical bug-for-bug
implementation that uses a socket to carefully pass along the same
environment or parameters to a native root binary, and the buffer overrun is
the same, guess what: you still have the same exploit.
I vehemently disagree. The thing with setuid/setgid is that the
invoked privileged process inherits a lot of implicit state and
context that people aren't really aware of or fully
understand. i.e. it's not just env vars and argv[], it's cgroup
memberships, audit fields, security contexts, open fds, child pids,
parent pids, cpu masks, IO/CPU scheduling priorities, various prctl()
settings, tty control, signal masks + handlers, … and so on. And it's
not even clear what gets inherited as many of these process properties
are added all the time.
If you do privileged execution of specific operations via IPC you get
the guarantee that whatever is done, is done from a well-defined,
pristine execution environment, without leaking context implicitly. The
IPC message is the *full* vulnerable surface, and that's as minimal as
it can get. And that's great.
So yes, setuid/setgid is a mess. Modern OS designs tend to follow the
rule that privs lost cannot be regained, and that's a much much better
design than what we do on Linux/UNIX.
(But I guess that ship has sailed, getting sudo out of the standard OS
is not going to work for a general purpose distro these days anymore —
but let's not pretend setuid/setgid was OK, because it's not.)
suid is not the problem. An execved program will inherit the
environment,
some open file descriptors, and maybe a few other things that a standalone
daemon that accepted a socket connection does not have. But that's what most
exploits leverage, so cleaning up the environment and open file descriptors
would remedy that. It will take some effort to exploit whatever
remains.
IRL you cannot clean up your execution context, because new stuff is
added all the time. And often enough it's not even clear whar reset it
to, e.g. cgroup stuff.
Lennart
--
Lennart Poettering, Berlin