oss-sec mailing list archives
Re: Healing the bash fork
From: "Kobrin, Eric" <ekobrin () akamai com>
Date: Tue, 30 Sep 2014 07:50:44 -0500
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
Current thread:
- Re: Healing the bash fork, (continued)
- Re: Healing the bash fork David A. Wheeler (Sep 29)
- Re: Healing the bash fork John Haxby (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Chet Ramey (Sep 29)
- Re: Healing the bash fork gremlin (Sep 29)
- Re: Healing the bash fork Florian Weimer (Sep 30)
- Re: Healing the bash fork Gennady Kupava (Sep 30)
- Re: Healing the bash fork gremlin (Sep 30)
- Re: Healing the bash fork Kobrin, Eric (Sep 29)
- Re: Healing the bash fork Michal Zalewski (Sep 29)
- Re: Healing the bash fork Kobrin, Eric (Sep 30)
- Re: Re: Healing the bash fork Todd C. Miller (Sep 29)
- atd (was: Re: [oss-security] Re: Healing the bash fork) Seth Arnold (Sep 29)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Christos Zoulas (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Tavis Ormandy (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 25)