Re: Issues with exported functions

[Eric Blake]

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