Re: Issues with exported functions

[David A. Wheeler]

I agree it would be MUCH better to append () to the "variable" name if it is a 
function export.  If that suffix can be included in the official bash release, 
I would be delighted.

There had been earlier claims that () might fail on old systems, but I have not 
seen evidence of it. I do not have access to really old systens to test... if 
anyone does that would be helpful.  At this point it might be best to focus on 
protecting current systems.







On September 27, 2014 2:19:49 AM EDT, Eric Blake <eblake@redhat.com> wrote:
>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

--- David A.Wheeler