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).