Re: CVE-2014-6271: remote code execution through bash

["David A. Wheeler" <dwheeler () dwheeler com>]

I think that the correct solution for this problem is *both*:
1. prefix (and maybe suffix) the environment variable names used for function exports, per Florian Weimer (and put in 
Red Hat), *and*
2. to only import environment variables by request, per Christos Zoulas (and put in FreeBSD).

This is a really nasty vulnerability; trying to fix the bash parser with endless whack-a-mole fixes just won't cut it.  
Both approaches have their advantages; applying both defenses results in a *much* stronger defense.

FYI, below is a post I just sent to bug-bash arguing the same point.

--- David A. Wheeler

==================

I appreciate the effort made in patch bash43-026, but this patch doesn't even BEGIN to solve the underlying shellshock 
problem. This patch just continues the "whack-a-mole" job of fixing parsing errors that began with the first patch. 
Bash's parser is certain have many many many other vulnerabilities; it was never designed to be security-relevant!

I strongly recommend *TWO* changes which have been discussed here and on oss-sec:
1. Add a prefix "BASH_FUNC..." (and maybe suffix) as proposed by Florian Weimer, per: 
http://www.openwall.com/lists/oss-security/2014/09/25/13
This is technically backwards-incompatible, but that will rarely matter. The specific environment variable mechanism 
was never documented in the bash man page, after all, and it works just fine if both sending & receiving bashes are 
patched. I would suggest NOT including the suffix "()", since some old systems might have trouble with such unusual 
environment variable names.
This change completely eliminates vulnerabilities from CGI and similar processing, where attacker data is being passed 
through environment variables to a receiving system. It also eliminates the punning that comes when functions and 
regular environment variables have the same name, which isn't really POSIX-compliant anyway.

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.

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

Thanks for listening!

--- David A. Wheeler