|
Message-Id: <20140927233330.55A2817FDA3@rebar.astron.com> Date: Sat, 27 Sep 2014 19:33:30 -0400 From: christos@...las.com (Christos Zoulas) To: chet.ramey@...e.edu, John Haxby <john.haxby@...cle.com>, oss-security@...ts.openwall.com Subject: Re: Re: CVE-2014-6271: remote code execution through bash (3rd vulnerability) On Sep 27, 6:46pm, chet.ramey@...e.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
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.