[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Sep 2014 07:50:44 -0500
From: "Kobrin, Eric" <ekobrin@...mai.com>
To: Michal Zalewski <lcamtuf@...edump.cx>
CC: "chet.ramey@...e.edu" <chet.ramey@...e.edu>, "dwheeler@...eeler.com"
<dwheeler@...eeler.com>, oss-security <oss-security@...ts.openwall.com>,
solar <solar@...nwall.com>, fweimer <fweimer@...hat.com>
Subject: Re: Healing the bash fork
On Sep 29, 2014, at 11:44 PM, Michal Zalewski <lcamtuf@...edump.cx> wrote:
>
> But if the prefix approach works fine, and nobody can come up with any
> compelling security-relevant reasons why it's a bad outcome... then
> what's the point of breaking existing scripts?
>
> I mean, all the arguments against the prefix approach boil down to
> "but if the attacker can set arbitrarily named variables to arbitrary
> values, then..." - and if that's something you allow across a security
> boundary, you're almost certainly in trouble no matter what.
>
It's a question of how far from the edge you like to live. How many different things must go wrong before we're back in shellshock land?
For example, Apache allows adversaries to choose environment variable suffixes. Imagine instead that a piece of software allows the adversary to choose prefixes instead (e.g. foo_HTTP instead of HTTP_foo). What if that adversary controlled input is "BASH_FUNC_foo%%\0" and that software uses c-strings?
We should take steps to make systems (even flawed systems) that depend on bash less prone to cause adversary-supplied code to run.
What advice do you give the author of a program[A] which will be invoked by software[B] that cedes too much control of the environment to the "user" if program[A] wants to invoke bash safely? Strip environment variables ending in "%%" ? Apple's patch didn't keep that suffix, plus this strategy requires a loop.
How can we help other software avoid enabling adversary access to the function-import pitfall? Here are some options, depending on the final design:
1. Create an environment variable which, if set, disables function import. Then calling programs can just set that value and know that if they invoke bash, any evil functions they inherited will be neutered.
2. Create an environment variable which contains the list of functions to import. Calling programs can then reduce this set to functions they wish to export or empty the variable to prevent import.
3. Store all functions in a single variable, in parsed form. Calling programs can empty this variable to disable function export.
The third option has the benefit that adversaries able to choose function names and values may find that other restrictions (character set, stricter re-parsing of this variable, etc.) make it hard to form an executable input. It's not a strong protection by itself but it can be implemented in a way that fails to expose parser infelicities, which could have prevented this issue in the first place.
-- Eric Kobrin
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.
