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.
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.
A more careful search located the sudo exploit you described, from 2014,
CVE-2014-0106. I couldn't find anything similar in sudo's history, so this
must be what you are referring to. Looks like it was in a non-default
configuration, and after reading up the details of the exploit:
The only argument I see here, is that if the isolated process-based
implementation of an sudo-alternative did not implement the non-env_reset
option in the first place. If it did implement the non-env_reset related
option, presumably there would've been some mechanism for the client to
transmit its environment to the isolated process, for the benefit of the
spawned subshell.
And it that turned out to be the case, the same exact bug would've happened.
The process isolation would not've accomplished anything, here. The problem
was not inherent with an suid-based approach. sudo had a broken
implemenation of an optional configuration setting. If it was broken in the
same way, in an isolated process, the lack of the setuid bit would not've
made any material difference.