[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Sep 2014 10:49:22 -0700
From: Tavis Ormandy <taviso@...xchg8b.com>
To: "Kobrin, Eric" <ekobrin@...mai.com>
Cc: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>, Florian Weimer <fweimer@...hat.com>,
"chet.ramey@...e.edu" <chet.ramey@...e.edu>, Michal Zalewski <lcamtuf@...edump.cx>,
Solar Designer <solar@...nwall.com>
Subject: Re: Healing the bash fork
On 29 September 2014 10:39, Kobrin, Eric <ekobrin@...mai.com> wrote:
> On Sep 29, 2014, at 11:59 AM, Eric Blake <eblake@...hat.com> wrote:
>
>> But I see no reason to move away from %% suffixing.
>
> The suffix fixes the obvious CGI hole, but it leaves exposed programs in which the adversary gets to choose the variable name as well.
>
> env $'BASH_FUNC_foo%%=() { echo 123\n }' bash -c "foo"
>
> I think that a more robust solution, such using a separate store for functions, is needed if function import is to survive as a feature.
>
> -- Eric Kobrin
If an adversary can choose the variable name, it's game over by
definition. He can choose LD_PRELOAD, SHELLOPTS='xtrace' PS4='$(foo)',
LD_DEBUG_OUTPUT, PYTHONINSPECT, etc, etc.
This general solution is robust, now we're just hammering out the details.
--
-------------------------------------
taviso@...xchg8b.com | pgp encrypted mail preferred
-------------------------------------------------------
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.
