[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140926181243.GT23797@brightrain.aerifal.cx>
Date: Fri, 26 Sep 2014 14:12:43 -0400
From: Rich Felker <dalias@...c.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: CVE-2014-6271: remote code execution through
bash (3rd vulnerability)
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
