On 09/26/2014 03:47 PM, David A. Wheeler wrote: > 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
The prefix is nice for quick identification, but what is ESSENTIAL is something that puts shell functions in a namespace that is untouchable by normal shell variables (the "()" suffix in Florian's patch). If all you do is add a prefix, but still leave the environment containing what can still collide with a shell variable name, you are still vulnerable. > 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. Well, what WOULD you suggest? There MUST be something that makes all exported functions use env-var names that CANNOT collide with shell variable names. Do you have proof of a system that chokes with () in the environment variable name? > 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. I am also in favor of both approaches - moving shell functions into a non-colliding namespace (so that arbitrary contents of regular variables CANNOT trigger parser bugs) and making shell function exports configurable and off by default. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
