Re: CVE-2014-6271: remote code execution through bash

[Eric Blake <eblake () redhat com>]

On 09/27/2014 08:05 PM, Eric Blake wrote:

> With your patch as-is:
>
> $ bash -c 'function a=b(){ echo oops;};export -f a=b;export
> BASH_FUNC_a=hi; bash
> -c "echo \$BASH_FUNC_a"'
> b%%=() { echo oops
> }
>
> Your attempt to export an invalid function name ended up clobbering a
> regular variable.  So I highly recommend that you further tighten things
> up to reject '=' in function names.  Here's your existing tightening line:
>
>
>         /* Don't import function names that are invalid identifiers from the
>            environment. */
> !       if (absolute_program (tname) == 0 && (posixly_correct == 0 ||
> legal_identifier (tname)))
> !         parse_and_execute (temp_string, tname,
>
> where absolute_program() filters anything with '/', and the use of
> posixly_correct decides whether to further restrict to variable names.

Thinking a bit further, the _import_ direction (this code) is just fine,
as is.  Anyone manually munging their environment will NOT get a
function named a=b, but a variable named BASH_FUNC_a (and it's their own
fault if they stick duplicates in environ).  But on the _export_
direction (or more properly, when handling the 'function' keyword
elsewhere in the source code), _that_ spot needs to be tightened to
reject = in the attempted function name creation.

I could live with it being a separate patch, as the import direction is
what is protecting us from Shell Shock, and the output direction is now
just a matter of clobbering regular variable names, but still think it
should be fixed.

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

Attachment: signature.asc
Description: OpenPGP digital signature