oss-sec mailing list archives
Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability)
From: Chet Ramey <chet.ramey () case edu>
Date: Sat, 27 Sep 2014 18:46:53 -0400
On 9/26/14, 8:47 AM, John Haxby wrote:
On 26/09/14 12:33, Florian Weimer wrote:On 09/26/2014 10:54 AM, Mark R Bannister wrote:Testing patch 25 and 26 from Chet, it looks to me like this is still an incomplete fix. The third vulnerability I'd like to report is the feature itself in bash that allows functions to be passed in the environment, e.g. $ env ls='() { echo vulnerable; }' bash -c ls This allows an attacker to replace a command used by a bash script with arbitrary code. It is then down to an attacker to find a suitable command that the bash script (or any child shells) might call without a path component. I can't see this being a problem for Apache custom headers (the variable name is turned to uppercase and prefixed by HTTP_), nor sudo commands if env_reset is on (the default), but this continues to be a major vulnerability for setuid/setgid scripts (S_ISUID or S_ISGID) where the environment is preserved.I agree this looks scary at first glance, but we discussed this previously, see for example: <http://www.openwall.com/lists/oss-security/2014/09/24/20> Shell scripts derive part of their power and flexibility from their openness to the execution environment. You can tweak PATH, BASH_ENV (or ENV for other Bourne-like shells), IFS, HOME, and many other variables to change behavior. There are even more knobs to affect the behavior of the external commands almost all shell scripts call when they run. This makes them not suitable at all for writing SUID programs or other code that runs in untrusted environments. This is well-documented, and given the amount of shell scripts out there which rely on these aspects of the UNIX shell design, it's not something we can change, particularly not as part of a security update which system administrators are more or less forced to install. In your specific example, you can achieve the same effect by setting PATH to a directory with a customer ls program, or by setting BASH_ENV to a file which contains a definition of a function called ls. Overriding external programs with shell functions in such a way has to be supported. Otherwise, scripts which define shell functions would break if the system administrator installs new software which happens to include a program of the same name of the shell function.It's not so much the known attacks -- redefining ls, unset, command, typeset, declare, etc -- it's the future parser bugs that we don't yet know about. A friend of mine said this could be a vulnerability gift that keeps on giving. CVE-2014-7169 was discovered very quickly after CVE-2014-6271. Do you think that's the end of it? (Just in case: I'm not getting at anyone here, certainly not Chet, Florian or anyone else who has been working overtime on these.) Importing functions from the environment is relatively unusual. I'd probably go so far as to say very unusual. Sufficiently unusual, I'd venture, that it should not be done implicitly. Florian's "BASH_FUNC_x()" makes it easier to blacklist these environment variables and ensures that a web server's HTTP_ prefix will not just create an oddly named function ... is that enough? Should bash simply make importing functions something that one has to ask for explicitly as Christos Zoulas (and others) suggested[1]?
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. 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/
Current thread:
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability), (continued)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Kobrin, Eric (Sep 29)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Chet Ramey (Sep 29)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Osmond Sun (Sep 29)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Giles Coochey (Sep 29)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Chet Ramey (Sep 29)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Giles Coochey (Sep 29)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Ed Prevost (Sep 29)
- RE: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Sona Sarmadi (Sep 29)
- Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Ramon de C Valle (Sep 29)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Loganaden Velvindron (Sep 27)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Chet Ramey (Sep 27)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Christos Zoulas (Sep 27)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Loganaden Velvindron (Sep 27)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Rich Felker (Sep 26)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Kurt Seifried (Sep 26)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Rich Felker (Sep 27)
- Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) Kurt Seifried (Sep 26)