Re: REGRESSION: shellshock patch rejects valid function names

[Eric Blake]

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

> 
> The problem is that it's too restrictive.  There are folks who have taken
> advantage of this flexibility to define, use, and export functions like
> 
> STD::what::does::this::do
> 
> which are no longer allowed.  This is a pretty bad break with backwards
> compatibility.

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.

> 
> So what's your opinion on the appropriate set of restrictions? This is a
> question that goes farther than what a particular shell will import,
> since I'm going to align the restrictions on what functions a shell will
> import from the environment with what functions that shell will let a
> user define.  That means that a posix-mode shell will require imported
> functions to be valid identifiers, but a non-posix mode shell will allow
> words.  The original check that was in bash-4.3 does this.  What additional
> checks should there be? I can see starting with rejecting function names
> that can be confused with pathnames.

I'm 50:50 between two options:

1: Have two sets of valid names.  In /bin/sh POSIX mode, functions can
only be variable names, and when /bin/sh is importing from the env, it
silently ignores or discards any mangled names that would not fit that
restriction; meanwhile, invoking a function is only possible if the
function name is a variable name; then in bash mode, functions can have
any name and be invoked by that name

2. Have only a single rule on what forms a valid name.  POSIX doesn't
forbid us from having an enlarged namespace for valid function names; a
strictly conforming application won't use such unusual names.  You may
still want to ignore or scrub those out of the environment during
/bin/sh importing, but that brings us back to the question of whether
function imports should be automatic, or something the user has to
explicitly request.  If ALL function imports are skipped unless
explicitly requested, then it doesn't matter WHAT function names are
exported, the incoming functions in a child shell (regardless of whether
the shell is in bash or /bin/sh mode) will have no impact to that child
unless the script programmer of the parent asked to have functions imported.

Thankfully, bash already forbids trying to name a function 'a=b' (having
to support such a name would make env-var export/import rather
difficult), so the main culprits that people seem to be worried about
are '-', '.', ':', and '/'.

> 
> (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; the only
violation I see is that the implementation is preventing the use of
arbitrary values of normal variables.  And the proposed fixes that use
an alternate namespace to avoid collisions have already resolved that issue.



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

signature.asc
Description: OpenPGP digital signature