Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 1 Oct 2014 17:53:45 -0700
From: Tavis Ormandy <>
Cc: Chet Ramey <>
Subject: Re: More parser odities

On Wed, Oct 1, 2014 at 5:36 PM, Solar Designer <> 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.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.