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

[christos () zoulas com (Christos Zoulas)]

On Sep 27,  6:46pm, chet.ramey () case edu (Chet Ramey) wrote:
-- Subject: Re: [oss-security] Re: CVE-2014-6271: remote code execution throu

| I think function exports are used more widely than you think, and I am not
| willing to break backwards compatibility that much by disabling function
| exports by default.

Let's think this through for a minute:

- subshells are just the results of fork() so they just work (functions
  are still loaded in memory).
- sourced scripts again are in the process image and just work.

So we are talking about functions that are inherited during exec,
either directly (by executing another bash script from the shell,
or running bash again.) or indirectly (some other command runs a bash
shell or script) or remotely (if you are passing function definitions
in your ssh environment).

Lets assume that we want to import for interactive shells, because
we want the user to have his familiar working setup; we can easily
do that because we know when the shell is interactive.

For non-interactive shell scripts, I'd say that the default behavior
should be off. If you want it on, turn it on explicitly. It is a
dangerous feature (being able to override commands in a way the
script does not expect). This was recognized before, this is why
it is off when you are setuid. Let's correct it.  You don't want
to be affecting the shell in such an intrusive way before the user
is given control and a choice. Let the people who want to use the
feature to have to turn it on explicitly.

I think some stuff might break, but it will be easily fixable and
worth the extra work because:

        - we would not be exposing the parser anymore
        - we would be starting up scripts in a more controlled environment

christos