Re: More parser odities

[Tavis Ormandy <taviso () google com>]

On Wed, Oct 1, 2014 at 5:36 PM, Solar Designer <solar () openwall com> wrote:
> Eric - you probably want to CC: Chet on your new findings.  Added the CC.
>
> On Wed, Oct 01, 2014 at 07:16:40PM -0500, Kobrin, Eric wrote:
> > This oddity also allows bypass of the absolute_program protection added in the recent patches:
> >
> >
> > $ env $'BASH_FUNC_#badname%%'=$'() { :; }\n/bin/ls () { echo wrongfunc; }  ' ./bash -c '/bin/ls'
> > fbash: error importing function definition for `#badname'
> > wrongfunc
> >
> >
> >
> >
> > I really do think it is time to take a different approach for a long-term solution.

Eric - the prefix you're specifying _is_ the long-term solution, it
may be a bug, but it's a non-security bug.

An attacker cannot set the _names_ of the variables across any
reasonable privilege boundary. The reason this was an issue recently
was because the name was irrelevant.

If you have some situation where an attacker can invoke bash *across a
privilege boundary* with arbitrary environment variable *names*, then
that is a bug in the program invoking bash - *not* a bug in bash.
Nothing bash can do can save you in that case, it is the
responsibility of that program to invoke bash safely.

This is like complaining that if you give someone your username and
password, bash lets you remove files. That's not bash's fault, it's
your fault for giving the attacker your username and password.

If you let an attacker specify arbitrary variable *names* across a
privilege boundary, that's *your* fault not bash's.

Tavis.