oss-sec mailing list archives
Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability)
From: christos () zoulas com (Christos Zoulas)
Date: Sat, 27 Sep 2014 19:33:30 -0400
On Sep 27, 6:46pm, chet.ramey () case edu (Chet Ramey) wrote: -- Subject: Re: [oss-security] Re: CVE-2014-6271: remote code execution throu | 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. Let's think this through for a minute: - subshells are just the results of fork() so they just work (functions are still loaded in memory). - sourced scripts again are in the process image and just work. So we are talking about functions that are inherited during exec, either directly (by executing another bash script from the shell, or running bash again.) or indirectly (some other command runs a bash shell or script) or remotely (if you are passing function definitions in your ssh environment). Lets assume that we want to import for interactive shells, because we want the user to have his familiar working setup; we can easily do that because we know when the shell is interactive. For non-interactive shell scripts, I'd say that the default behavior should be off. If you want it on, turn it on explicitly. It is a dangerous feature (being able to override commands in a way the script does not expect). This was recognized before, this is why it is off when you are setuid. Let's correct it. You don't want to be affecting the shell in such an intrusive way before the user is given control and a choice. Let the people who want to use the feature to have to turn it on explicitly. I think some stuff might break, but it will be easily fixable and worth the extra work because: - we would not be exposing the parser anymore - we would be starting up scripts in a more controlled environment christos
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) 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)