oss-sec mailing list archives
Re: Healing the bash fork
From: Gennady Kupava <gennady.kupava () gmail com>
Date: Tue, 30 Sep 2014 12:37:34 +0100
We need to keep support exporting functions to grandchildren through
non-bash processes (that is, bash -> some-other-program -> bash) But the way bash does such export right now is undefined behavior according to UNIX definitions. If you export some function and the variable with same name you will get two environment variables with same name, isn't this kind of bad design in any case? 2014-09-30 10:30 GMT+01:00 Florian Weimer <fweimer () redhat com>:
On 09/30/2014 05:11 AM, gremlin () gremlin ru wrote:On 29-Sep-2014 22:34:20 -0400, Chet Ramey wrote: >> What is the motivation to not store executable code (functions) >> differently from standard variables? > What would you use for such a store, considering the environment > is the only portable way to pass this information from one process > to another in the general case, and support the current set of > use cases? C.O. to the rescue: temporary file.You cannot use a named temporary file because the creator does not know its required lifetime. That's a challenge all solutions not based on the process environment will face. Theoretically, you could pass an unnamed temporary file via a file descriptor, and communicate the descriptor number in some safe way (but what's that, if you don't trust the environment?). But that's going to be far less interoperable than what we currently have, and barely more secure. If one shell instance needs to pass some functions to another, itcould dump those functions to a temporary file and pass the --load (or, better, --load-functions) options with a filename parameter.We need to keep support exporting functions to grandchildren through non-bash processes (that is, bash -> some-other-program -> bash). -- Florian Weimer / Red Hat Product Security
Current thread:
- Healing the bash fork (was: Re: [oss-security] CVE-2014-6271: remote code execution through bash), (continued)
- Healing the bash fork (was: Re: [oss-security] CVE-2014-6271: remote code execution through bash) Florian Weimer (Sep 29)
- Re: Healing the bash fork Eric Blake (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Tavis Ormandy (Sep 29)
- Re: Healing the bash fork David A. Wheeler (Sep 29)
- Re: Healing the bash fork John Haxby (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Chet Ramey (Sep 29)
- Re: Healing the bash fork gremlin (Sep 29)
- Re: Healing the bash fork Florian Weimer (Sep 30)
- Re: Healing the bash fork Gennady Kupava (Sep 30)
- Re: Healing the bash fork gremlin (Sep 30)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Michal Zalewski (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 30)
- Re: Re: Healing the bash fork Todd C. Miller (Sep 29)
- atd (was: Re: [oss-security] Re: Healing the bash fork) Seth Arnold (Sep 29)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Christos Zoulas (Sep 25)