[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <54254F01.3050502@redhat.com>
Date: Fri, 26 Sep 2014 13:33:21 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: CVE-2014-6271: remote code execution through
bash (3rd vulnerability)
On 09/26/2014 10:54 AM, Mark R Bannister wrote:
> Testing patch 25 and 26 from Chet, it looks to me like this is still an incomplete fix. The third vulnerability I'd like to report is the feature itself in bash that allows functions to be passed in the environment, e.g.
> $ env ls='() { echo vulnerable; }' bash -c ls
>
> This allows an attacker to replace a command used by a bash script with arbitrary code. It is then down to an attacker to find a suitable command that the bash script (or any child shells) might call without a path component.
>
> I can't see this being a problem for Apache custom headers (the variable name is turned to uppercase and prefixed by HTTP_), nor sudo commands if env_reset is on (the default), but this continues to be a major vulnerability for setuid/setgid scripts (S_ISUID or S_ISGID) where the environment is preserved.
I agree this looks scary at first glance, but we discussed this
previously, see for example:
<http://www.openwall.com/lists/oss-security/2014/09/24/20>
Shell scripts derive part of their power and flexibility from their
openness to the execution environment. You can tweak PATH, BASH_ENV (or
ENV for other Bourne-like shells), IFS, HOME, and many other variables
to change behavior. There are even more knobs to affect the behavior of
the external commands almost all shell scripts call when they run.
This makes them not suitable at all for writing SUID programs or other
code that runs in untrusted environments. This is well-documented, and
given the amount of shell scripts out there which rely on these aspects
of the UNIX shell design, it's not something we can change, particularly
not as part of a security update which system administrators are more or
less forced to install.
In your specific example, you can achieve the same effect by setting
PATH to a directory with a customer ls program, or by setting BASH_ENV
to a file which contains a definition of a function called ls.
Overriding external programs with shell functions in such a way has to
be supported. Otherwise, scripts which define shell functions would
break if the system administrator installs new software which happens to
include a program of the same name of the shell function.
--
Florian Weimer / Red Hat Product Security
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.
