Re: Bash security issue

[Eric Blake]

On 09/26/2014 02:22 PM, Linda Walsh wrote:
> Eric Blake wrote:
> 
>> They are not portable to broken bash.  But the argument in these threads
>> is that bash's implementation of function exports should be changed so
>> that _fixed_ bash will once again be POSIX compliant and let this
>> bog-standard assignment work regardless of contents.  If Chet accepts
>> Florian's patch [1] to change function exports to use BASH_FUNC_foo()=
>> instead of foo= (which is what Red Hat is already using in their fixes
>> pushed today), then this POSIX compliance bug in broken bash will be
>> avoided.
>>
>> [1] http://www.openwall.com/lists/oss-security/2014/09/25/13
>>
> ----
> IS this added only in memory? I.e. no changes to source code?
> 
> What prevents BASH_FUNC_foo = '(){ :; ...';

Nothing, as you wrote it, because you have no () on the left of the
equal.  Florian's patch makes it so that the child bash sees your
example as a NORMAL variable, and so you get "echo $BASH_FUNC_foo"
outputting "(){...".  What matters is that 'export -f foo' results in
'BASH_FUNC_foo()=...' in the environment (note the parens on the left of
the equal).  As this is NOT a valid shell variable name, you have now
cleanly separated the namespace, and arbitrary contents of a shell
variable can no longer be coerced into a function.

And yes, you could still pass this arbitrary name via env or other
means, but remember that this exploit is not about the NAME of the
variable, but that arbitrary CONTENTS of a fixed name in the environment
were parsed rather than being treated as a string literal (in violation
of POSIX).  By separating namespaces, bash no longer violates POSIX, and
programs like apache that stick arbitrary contents into fixed-name
variables (but which do NOT create arbitrary-name variables) are no
longer subject to the parser intercepting their contents.

> 
> Why is there a need for a long prefix on top of switching
> the ()/= order?

only to make it all the more clear that this is a hand-shaking mechanism
between bash parent and child, and NOT something that most other
processes will care about.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature