Re: CVE-2014-6271: remote code execution through bash

[Chet Ramey <chet.ramey () case edu>]

On 9/24/14, 2:54 PM, Michal Zalewski wrote:
> > My main concern with the current patch is that still exposes the bash parser
> > and function definition printer to attacks from the network. Bugs in those
> > fairly large components could cause another critical issue.
>
> Yup, that surprised me when testing the patch, too - I can still get a
> function called HTTP_COOKIE, for example. I worry about potential side
> effects of parsing even in absence of parser bugs. In most
> object-oriented languages, such side effects are practically
> guaranteed. Bash may be saved by simplicity, but not sure how robust
> that assumption is.

Lots of code out there uses exported functions.

> I've written more code in bash than I should have and never used
> function exports, or even realized that they exist. I wonder if they
> can be made optional (e.g., gated by a flag on the subprocess) without
> breakage.
>
> Another option may be to export them through specially prefixed
> variables, which should be transparent but minimize the risk of
> interfering with web servers and such.

There are several options for making shell functions inherited via the
environment more robust, none of them backwards compatible.  I will
choose one and implement it for a future bash version.

The leading candidates both raise the bar by requiring a potential
attacker to be able to create arbitrarily-named environment variables as
well as environment variables with specific values.

I considered (and implemented) a blacklist approach that would have
protected against a set of commonly-named variables (HTTP_*, CGI_*,
SSH_*, LC_*, and so on), but the consensus was that that was too easily
circumvented.  I removed it from the distributed patches.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet () case edu    http://cnswww.cns.cwru.edu/~chet/