bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: REGRESSION: shellshock patch rejects valid function names


From: Eric Blake
Subject: Re: REGRESSION: shellshock patch rejects valid function names
Date: Sat, 27 Sep 2014 18:49:39 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

On 09/27/2014 05:59 PM, Chet Ramey wrote:
> On 9/27/14, 4:29 PM, Eric Blake wrote:
>> On 09/27/2014 12:53 PM, Chet Ramey wrote:
> 
>> Right now, we know of no way for an attacker to force an arbitrary
>> variable name - ONLY arbitrary variable contents.  
> 
> Sure, but we didn't know that at the time.  We still don't, really.

On the bright side: _if_ we find a way for an attacker to generate an
arbitrary variable name in a parent process before calling into bash,
that is more likely to be raised as a security bug against THAT program,
and not bash.  The reason bash is getting the limelight for
CVE-2014-6271 is because there are so many existing programs that pass
untrusted input to environment variable values, where fixing bash solves
ALL of those cases at once; but there are a lot fewer (if any) programs
stupid enough to create arbitrary environment variable names.

The regression with 'at' failing to work is because 'at' is making
unportable assumptions that the environment it is passed will always be
parsable in shell.  But this assumption is wrong whether or not bash
uses an alternate namespace for function exports - ANY C program that
uses execve can tickle that bug in 'at'.  So that particular fix is not
bash's problem, but 'at's problem.


> 
>> Exactly, this break is undesirable.  Remember, the security hole of
>> Shell Shock is NOT what the function is named, but the fact that
>> arbitrary variable contents were being parsed.  Once you plug that hole
>> by sticking function import/export in a separate namespace, then there
>> should be no problem in allowing ALL function names that have always
>> been previously allowed.
> 
> We have an opportunity to close up a potential problem here, at least
> with respect to function names containing `/'.

As I said in a later mail, I'm now definitely leaning towards your
desire to exclude '/', and may I also add '=', as two characters that
will be blacklisted from valid function names both in the shell and
during import/export, because they are just too risky.  I haven't yet
come up with any reason to blacklist any other non-metacharacter, and
you already reject any metacharacter that requires quoting.


> I'm not really interested in the function-importing-by-default discussion
> right now.  Maybe sometime later.  It's more of a break with backwards
> compatibility than I'm willing to go at this point.

That's a fair stance.  I don't mind waiting and revisiting that
discussion later; I agree that the first priority is to plug the
namespace issue.


>>> (And I'm not interested in rehashing decisions that were made 25 years
>>> ago, and I am completely aware that this "violates" Posix.  That's why it
>>> doesn't do this in posix mode.)
>>
>> I don't see function export/import as a violation of posix; 
> 
> Yeah, but what I was talking about was allowing non-identifiers as valid
> function names.

Where does POSIX forbid the use of a non-identifier as a valid function
name?  My understanding is that:

a:b () { ... }

is unspecified by POSIX (and NOT expressly required to be a syntax
error), which has two implications: 1. Strictly-conforming shell scripts
will not attempt to use it, and 2: we are allowed to support it as an
extension while still remaining POSIX compliant.  I'd need to see an
example of some script that would be parsed one way with bash's function
name extensions and a different well-defined way by a strict reading of
POSIX before stating that /bin/sh mode must behave differently at having
a smaller subset of valid function names.

-- 
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

[Prev in Thread] Current Thread [Next in Thread]