Re: Healing the bash fork

["Kobrin, Eric" <ekobrin () akamai com>]

On Sep 29, 2014, at 11:44 PM, Michal Zalewski <lcamtuf () coredump 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