On 09/27/2014 08:50 PM, Chet Ramey wrote:
>                            BASH PATCH REPORT
>                            =================

>         /* Don't import function names that are invalid identifiers from the
>            environment, though we still allow them to be defined as shell
>            variables. */
> !       if (absolute_program (tname) == 0 && (posixly_correct == 0 || 
> legal_identifier (tname)))
> !         parse_and_execute (temp_string, tname, 
> SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);

This patch forbids importing function names containing '/' (yay!), and
we already established that bash has never been able to properly import
functions with names containing '='.  But I'm assuming there will need
to be a followup patch to actually reject the attempt to create such
function names (that is, "bash -c 'a/b () { echo oops; }; a/b'" should
issue an error message instead of printing "oops"), so that we do not
have the confusing situation of being unable to pass all permitted
function names through an export/import cycle.

By the way, thanks for this patch - it plugs CVE-2014-7186,
CVE-2014-7187, and CVE-2014-6277 (and probably other parser crashes)
from remote exploits down to merely annoying local bugs that can no
longer be abused for privilege escalation.  In other words, it is THIS
patch that plugs the Shell Shock issue, even though there are still more
patches needed to plug all of the parser holes that Shell Shock has
uncovered.

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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to