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

[Solar Designer <solar () openwall com>]

On Wed, Sep 24, 2014 at 03:12:08PM -0400, Chet Ramey wrote:
> 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.

What about no longer inheriting functions with names that don't contain
any lowercase letters?  I guess typical function names use some lowercase
letters (are all-lowercase, or also contain non-letters, or use
CamelCaps), whereas typical names of environment variables set by
network services do not contain any lowercase letters (usually consist
of uppercase letters and underscore only).  This is not pretty, but it
isn't as limited as a blacklist of specific prefixes would be, so maybe
it'd work reasonably well for an interim period until you're able to
break backwards compatibility to a greater degree?

Alexander