[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140926175541.GS23797@brightrain.aerifal.cx>
Date: Fri, 26 Sep 2014 13:55:41 -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 01:41:45PM +0100, Mark R Bannister wrote:
> Arguments that people shouldn't have setuid shell scripts don't
> stack up, because even if you write your setuid program in some
> other language, you might unwittingly exec something written in
> bash.
> As /bin/sh is symlinked to /bin/bash in RHEL, the moment you call
> out to the system to do a piece of work for you, you're at risk of
> invoking bash and thereby being vulnerable to a root exploit. For
> example:
>
> $ env bzip2='() { echo vulnerable >&2; }' /usr/bin/bzdiff /tmp/file1.bz /tmp/file2.bz
>
> $ env test='() { echo vulnerable >&2; }' /usr/bin/ldd /usr/bin/gcc
>
> So this is not about whether or not someone has written a setuid
> shell script. This has uncovered a potential new exploit for any
> setuid program. Indeed the very first setuid program that I
> discovered this exploit with was a binary (compiled C program) that
> happened to exec ldd while it was running.
>
> I don't think this issue can be swept under the carpet.
Any setuid program that's execing an external program that was not
also designed to be run setuid, without scrubbing the environment and
other environmental state (rlimits, inherited file descriptors, ...),
or else fully dropping privileges to the original invoking user, is a
gaping security hole already. This has nothing to do with bash.
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.
