[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE-2014-6271: remote code execution through bash
From:       "David A. Wheeler" <dwheeler () dwheeler ! com>
Date:       2014-09-26 22:26:44
Message-ID: E1XXdyO-0002CJ-Ok () rmm6prod02 ! runbox ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]