[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140925001402.GA2702@openwall.com>
Date: Thu, 25 Sep 2014 04:14:02 +0400
From: Solar Designer <solar@...nwall.com>
To: Chet Ramey <chet.ramey@...e.edu>
Cc: oss-security@...ts.openwall.com
Subject: Re: CVE-2014-6271: remote code execution through bash
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
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.
