Lennart Poettering writes:
On Fr, 28.01.22 18:16, Sam Varshavchik (mrsam@xxxxxxxxxxxxxxx) 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 none of that makes any difference, whatsoever, unless there's also an underlying logical bug in the code itself. And that's going to be the real problem. So then, question becomes, how many exploits leveraged any of these exotic resources, like cgroup members, tty control, and all of those other fringe attributes? I suppose there might've been a few, but I can't recall many. On the other hand, exploits that accomplish execve("/bin/bash") would work equally well, given the same underlying bug in the root daemon, that's triggerable via its front end, or in a suid program. A sanitized environment won't be much of a help.
Give me a suid program doing a fgets() with a wrong buffer size on a stack array. Then also give me a program that connects to a root daemon over a socket, then simply forwards all input to it, with the root daemon also doing the same exact buffer overrun. The exploit will be the same. The root daemon's pristine, pure as wind-driven snow, environment won't make any difference.
In fact, having extra moving pieces only breeds more opportunities for bugs. There are still too many simpletons who are going to conclude that the right way to go is by doing all edit checking in the wrapper, then passing validated data to the daemon who'll assume its validity.
"The more you overthink the plumbing, the easier it is to stop up the drain." – Scotty, Star Trek III.
> 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.
Stuff that's "added all the time" won't be used in existing code base, and will be immaterial. None of the stuff from semi-recent history (containers, CPU affinities, etc…) appears to have much effect on my existing setup.
Attachment:
pgpiYeBH0uzEt.pgp
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
