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:05:02 -0600
From: Eric Blake <eblake@...hat.com>
To: chet.ramey@...e.edu, Tavis Ormandy <taviso@...xchg8b.com>,
        Florian Weimer <fw@...eb.enyo.de>
CC: Michal Zalewski <lcamtuf@...edump.cx>, Solar Designer <solar@...nwall.com>,
        oss-security@...ts.openwall.com
Subject: Re: CVE-2014-6271: remote code execution through bash

On 09/27/2014 07:39 PM, Chet Ramey wrote:
> On 9/27/14, 2:17 PM, Chet Ramey wrote:
>> On 9/27/14, 10:28 AM, Tavis Ormandy wrote:
>>
>>> It does look bad, but are you sold on the prefix/suffix solution Chet?
>>> That will at least mean these are not security issues.
>>
>> Yes.  I have no problems worth mentioning with the exported function
>> encoding approach.  I have attached patches implementing it that can
>> be applied to bash versions from bash-2.05b to bash-4.3.  Please take
>> a look, make sure they can be applied cleanly, and so on.
>>
>> There is another discussion worth having before officially releasing
>> these, which I will do later today.
> 
> OK, here are the more-or-less final versions of the patches for bash-2.05b
> through bash-4.3.  I made two changes from earlier today: the function
> export suffix is now `%%', which is not part of a the set of valid variable
> name characters but avoids any potential problems with including
> shell metacharacters in the name;

Nice compromise.

> and this version refuses to import shell
> functions whose name contains a slash, for reasons I discussed earlier.
> 
> Please let me know if you have any issues with these.

I'm still a bit worried about the fact that people can do 'function a=b
() { echo oops; }'; on the outgoing direction, this puts:

BASH_FUNC_a=b%%=() { echo oops; }

into the environment, and on the incoming direction that means that you
have populated $BASH_FUNC_a as a _regular_ variable with contents "b%% {
echo oops; }'.  The parser is not run (so we are immune to Shell Shock),
but you are polluting the child namespace with a regular variable that
the parent did NOT export.

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.


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


[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

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