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:15:07 -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 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; 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 also worried about this:

  	  /* 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,

One of the complaints upstream is that:
>> Yes, it does do this detection, but too late for our concern, since things 
>> occur in the following order:
>>  (1) set_shell_name(argv[0]) => this detects "sh" and sets 'act_like_sh'
>>  (2) shell_initialize() => this decides to import funcs from env depending on 
>> flags like 'posixly_correct'
>>  (3) if (act_like_sh) ... sv_strict_posix ("POSIXLY_CORRECT")

Are you 100% sure that posixly_correct is correctly initialized at this
point in parsing the incoming environment variables, regardless of
whether you invoked '/bin/sh', 'bash -o posix', or 'POSIXLY_CORRECT=1
bash'?  I'm especially worried about the latter - if 'FUNC_BASH_a:%%=()
{...}' occurs in the environment earlier than 'POSIXLY_CORRECT=1', then
you may end up allowing function 'a:' in the namespace because you
didn't realize you should have been in posix mode.  Note - I have not
audited the code to see if you do a getenv("POSIXLY_CORRECT") (or
equivalent) prior to the processing loop of parsing incoming environment
variables in general, but since you are more familiar with the code
base, I'm hoping you can give a reassuring answer.

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