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.