oss-sec mailing list archives
Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability)
From: Guido Berhoerster <gber () opensuse org>
Date: Fri, 26 Sep 2014 15:11:59 +0200
* Florian Weimer <fweimer () redhat com> [2014-09-26 13:33]:
On 09/26/2014 10:54 AM, Mark R Bannister wrote: 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.
I strong disagree that, there is a big difference in that a script can (and should) be able to obtain a sane environment by resetting stuff like PATH, BASH_ENV, IFS. The issue is also not about flexibility to override commands with functions or the ability to export them, rather it is the apparently undocumented implementation mixing data and code by storing the functions in the environment which is total and utter crap even by the standards of 20 years ago and it is just a matter of time until the next parser bug comes up.
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.
That is orthogonal to the implementation of exported functions. -- Guido Berhoerster
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) 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)