Lennart Poettering writes:
On Di, 01.02.22 07:14, Sam Varshavchik (mrsam(a)courier-mta.com)
wrote:
> Lennart Poettering writes:
>
> > On Mo, 31.01.22 18:32, Sam Varshavchik (mrsam(a)courier-mta.com) wrote:
> >
> > > Lennart Poettering writes:
> > >
> > > > See the discussion around seccomp and NNP. i.e. a new kernel
facility
> > > > was added precisely to ensure that seccomp cannot be used to run
code
> > > > that is intended to be run privileged – under security policies in
> > > > control by an unprivileged user. i.e. if you can take certain privs
> > > > away from code that expects to have them you might be able to
trigger
> > > > vulnerable codepaths that the developer didn't expect you to be
able
> > > > to trigger.
> > > >
> > > > But anyway, don't focus so much in cgroups here. There are
plenty
> > > > other props these days that sudo doesn#t clean up. consider this for
> > >
> > > Ok, so where's the track record of potential security exploits, in
similar
> > > kinds of tools, that: 1) leverage any of the resources that you
mentioned,
> > > and 2) but were mitigated, and became ordinary bugs, thanks to the
> > > vulnerable code being an isolated daemon process, with a clean
> > > environment.
> >
> > I already described you a vulnerability. And the vulnerabilities in
>
> I must've missed those descriptions. Is there a reference somewhere that I
> can read, which describes them.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
I explained a locking DoS there: run privileged code, but with
extremly restrictive resource scheduling settings, so that it will
acquire privileged resources such as locks (which it can, since it is
privileged) but is extremely slow to give up again since it runs
awfully slow, due to the extremely restrictive resource settings which
are under control of an unpriv caller.
And an isolated process will be capable of rate-limiting itself in this
situation any better than a sudo process, which could do the same kind of
rate-limiting itself, exactly how?
About the only thing that works to its advantage is that it'll be in a
better position to employ rate limiting, by its virtue of being persistent.
But if this is a concern, there's a much better, hybrid approach. The user-
initiated executable would be a setuid executable that connects to a
filesystem socket, with the permissions adjusted so that only a privileged
process can connect to it.
This mitigates resource attacks that establish connections to the persistent
daemon, and just hold them open, without doing anything. Depending on the
particulars the setuid executable could do its own sanity checks first,
before establishing a connection to the persistent daemon, for the next step
in the process.
The suid bit itself is not a problem. Much like everything else, it is a
useful tool when used correctly. But just because it is used incorrectly,
sometimes, doesn't make it bad. And I tend to avoid making an absolute one-
size-fits-all, blanket assumption on the order of "X is bad". That's a bit
simplistic, and too naive for my taste. I'd rather take a look at each
individual situation, on its own merits, and figure out the best solution.
An excellent example would be what happened to OpenSSH. My understanding is
that they shuffled off all authentication stuff into a separate daemon that
runs with restricted privileges. This is not quite a good analogue for sudo,
there is no setuid bit involved here. But this is the right approach:
analyze the individual situation, and figure out the best solution. For
OpenSSH it seems to be what they picked to do, which makes a lot of sense.
> > sudo from not cleaning up env vars are pretty well
documented, too no?
> > And they are the same kind: not cleaned up context.
>
> A basic search finds the most recent sudo exploit was a heap based buffer
> overflow in sudo about a year ago. Something that can equally happen in an
> isolated process, too, if triggered the same way.
CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646,
CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629,
CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, …
These are all env var cleanup issues in su/sudo context.
Picking a few of them, at random:
CVE-2006-0151:
https://bugzilla.redhat.com/show_bug.cgi?id=139478
# Statement for NVD:
#
# If an administrator is concerned that users who have been granted sudo
# privileges can alter the environment, the existing "env_reset" option should
# be used which cleans the whole environment.
Mic drop.
CVE-2005-3629: this is initscripts, not sudo, the topic here.
CVE-2008-3825: this is PAM, not sudo.
CVE-2014-9680:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1191144
Looks like env_reset does not reset the TZ variable – that's a bug in that
option. Going back to the current thought experiment: what if sudo was a
persistent daemon?
Well, this CVE actually proves my point: a persistent daemon would not've
made any difference, whatsoever! If all the other sudo drivers were still in
play, I'm fairly confident that the same exact bug would've happened, and
having an isolated process would not've done anything.
TZ was intentionally excluded from sudo's clean environment. Why's that?
Well, I can see sudo's original line of thinking, crystal clear: it would've
been rather rude for the spawned subshell to pop up in a different timezone.
So, sudo intentionally did not launder TZ for that exact reason.
Well, if the same drivers were in place on the alternate-Earth, where sudo
used an isolated daemon, the same drivers would've been present, and the
alternate-sudo would've made arrangements for the caller's TZ to be carried
to the spawned subshell, overriding the isolated daemon's inherited TZ.
End result: same thing.