[Top][All Lists]

[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 15:01:18 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

On 09/27/2014 02:29 PM, Eric Blake wrote:
> On 09/27/2014 12:53 PM, Chet Ramey wrote:
>> $ function /bin/echo () { builtin echo whoops; }
>> along with exporting these functions and importing them without complaint.
>> This is obviously bad, and I removed the ability to do this in the first
>> patch in the event that someone figured out an easy way to remotely
>> specify an arbitrary variable name before we implemnted something to stop
>> it.
> Right now, we know of no way for an attacker to force an arbitrary
> variable name - ONLY arbitrary variable contents.  So I would prefer a
> patch that allows the export/import of the exact same set of names as
> what can be used as valid function names.  Neither set should be larger
> than the other, and for back-compat purposes, at least in bash mode, the
> set needs to STILL allow for functions named 'foo::bar' or 'foo/bar'.

After thinking a bit more, I would be in favor of a patch that forbids
'/' in function names, but opposed to a patch that forbids '.'.  '/' has
special effects on PATH lookup, and it is just too confusing to think
that in bash mode, a function could override a command name containing a
slash (especially since that should NOT be possible in /bin/sh mode, for
POSIX compliance).  ksh allows '.' in function names, so we would be
needlessly incompatible if we restrict that.  As for other
non-metacharacters, I'm just fine with allowing pretty much anything
else (',', ':', '@', '-'), as none of them have special rules on shell

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]