[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <E1XXdyO-0002CJ-Ok@rmm6prod02.runbox.com>
Date: Fri, 26 Sep 2014 18:26:44 -0400 (EDT)
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: "oss-security" <oss-security@...ts.openwall.com>,
"chet.ramey" <chet.ramey@...e.edu>
Subject: Re: CVE-2014-6271: remote code execution through bash
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
