Re: Bash-4.3 Official Patch 27

[Stephane Chazelas]

2014-09-27 22:48:44 -0600, Eric Blake:
> On 09/27/2014 08:50 PM, Chet Ramey wrote:
> >                          BASH PATCH REPORT
> >                          =================
> 
> >       /* Don't import function names that are invalid identifiers from the
> >          environment, though we still allow them to be defined as shell
> >          variables. */
> > !     if (absolute_program (tname) == 0 && (posixly_correct == 0 || 
> > legal_identifier (tname)))
> > !       parse_and_execute (temp_string, tname, 
> > SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
> 
> This patch forbids importing function names containing '/' (yay!), and
> we already established that bash has never been able to properly import
> functions with names containing '='.  But I'm assuming there will need
> to be a followup patch to actually reject the attempt to create such
> function names (that is, "bash -c 'a/b () { echo oops; }; a/b'" should
> issue an error message instead of printing "oops"), so that we do not
> have the confusing situation of being unable to pass all permitted
> function names through an export/import cycle.
[...]

I'd say it's unfortunate that the fix for CVE-2014-6271 removes
the support for exporting functions with slash in their name.

functions share the same namespace as other commands (and not as
variables which is also why the original implementation of
function exports was flawed/inconsistent), so it would make
sense to allow any name for a function.

Exported functions was a usefully debugging tool. You could do
things like:

env rm='() { [ "$1" = want-to-keep ] || command rm "$@"; }
  ' /bin/rm='() { [ "$1" != want-to-keep ] && command rm "$@"; }
  ' my-command

To avoid want-to-keep be removed by my-command eventually
running system("/bin/rm want-to-keep").

I guess I'll have to switch to zsh now (using $ZDOTDIR/.zshenv) for
this kind of trick.

In zsh, any function name is allowed, even the empty
string, even those with spaces or NUL characters, using quoting:

$'\0' () echo I am the nul command

Or

'my command' () echo spaces in my name...

Forbidding functions (even importing them) with those names
doesn't bring any significant security benefit AFAICT.

>From what I understand, it was done as a simple fix to avoid
problems with env vars whose name contains shell code and
because bash parser does not support defining functions with
arbitrary names like zsh does.

A better fix, IMO, would have been to allow any name in a
function name, or allow the same names from imported functions
as for functions declared normally.

I'd agree that if you can no longer import them, not allowing
declaring them would make sense, but might break existing
scripts which rely on that ability.

Also, as I said before, what is deemed a valid identifier is
locale specific (and there's a bug in that it only works
properly in single-byte locales), so one can still make locales
where "("` or "=" are part of valid identifiers.

-- 
Stephane