Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability)

[Rich Felker <dalias () libc org>]

On Fri, Sep 26, 2014 at 02:06:21PM +0100, Simon McVittie wrote:
> > Tell everyone to stop using setuid/setgid now and forever?

Yes!

> Minimizing use of setuid/setgid, and making sure the setuid/setgid
> things are suitably hardened, is a good idea. However, tools for
> controlled privilege escalation (sudo, pkexec, Apache suexec) rely on
> setuid in order to work. There's a reason the feature exists at all.

These could all be done by having the process with root privileges
inherit them from a daemon parent that already has root, rather than
requiring the kernel to elevate the privileges of a process via the
setuid bit. This inherently eliminates all attacker control of the
process's initial state and limits the input/attack surface to the
communication channel clients have with the daemon (e.g. a single unix
socket).

As a bonus, a kernel that completely lacks setuid/setgid support
immediately allows you to do lots of other security/functionality
enhancements, like allowing any process to chroot at any time,
allowing bind-mount-like filters blocking/replacing a process's view
of part of the filesystem, etc.

> I still think a large part of the answer is "consider it to be a serious
> bug when a setuid/setgid tool does non-trivial things without first
> filtering its attacker-controlled environment through a whitelist".

The problem with this is that the environmental state (I don't mean
just env vars, but everything a process inherits) is not of fixed
scope, but continually growing, and each new feature added is a
potential channel through which an attacker controls the behavior of
the setuid process.

Rich