[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues with exported functions

From: Ángel González
Subject: Re: Issues with exported functions
Date: Sun, 28 Sep 2014 18:31:16 +0200

David A. Wheeler wrote:
> 2. Import environment variables *ONLY* when they are requested; do *NOT* 
> import them by default.  Christos Zoulas has proposed this.  This *IS* a real 
> backwards-incompatible change.  But most users do *NOT* use this 
> functionality, and increasingly downstream systems are *already* switching to 
> this mode.  E.G., FreeBSD has already switched to this; function imports 
> require --import-functions or enabling the IMPORTFUNCTIONS option.   E.G., 
> see: https://svnweb.freebsd.org/ports?view=revision&revision=369341
> This change eliminates the entire class of problems.  It's still good to do 
> #1, even with #2, because if someone DOES perform an import, it reduces the 
> probability of accidentally importing the wrong thing.  People are ALREADY 
> making this change, whether upstream does or not.

There's also the middleground of not parsing the environment variables
before they are going to be used. That avoids the issues caused by
parsing what is not needed *and* doesn't break backwards compatibility.
See the patch I sent a couple days ago.

> John Haxby recently posted that "A friend of mine said this could be a 
> vulnerability gift that keeps on giving." 
> (http://seclists.org/oss-sec/2014/q3/748).  Bash will be a continuous rich 
> source of system vulnerabilities until it STOPS automatically parsing normal 
> environment variables; all other shells just pass them through!   I've turned 
> off several websites I control because I have *no* confidence that the 
> current official bash patches actually stop anyone, and I am deliberately 
> *not* buying products online today for the same reason.  I suspect others 
> have done the same.  I think it's important that bash change its semantics so 
> that it "obviously has absolutely no problems of this kind".

That's exactly what my patch does, although it wouldn't be transparent
if used inside bash (eg. echo $FUNC), as opposed of usage by its
children (wouldn't be hard to change, though).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]