Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Sep 2014 20:20:11 -0600
From: Eric Blake <>
To:, Tavis Ormandy <>,
        Florian Weimer <>
CC: Michal Zalewski <>, Solar Designer <>,
Subject: Re: CVE-2014-6271: remote code execution through bash

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

Download attachment "signature.asc" of type "application/pgp-signature" (540 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ