Re: Re: Non-upstream patches for bash

[Ángel González <angel () 16bits net>]

John Haxby wrote
> On 26/09/14 01:23, Ángel González wrote:
> > Forwarding to the oss-security thread the patch I sent to bug-bash 
> > 1 hour ago.
> >
> > The trick here is to delay parsing of functions coming from the
> > environment until they are actually needed.
> >
> > Thus extra code (CVE-2014-6271) or even a parsing vulnerability like
> > CVE-2014-7169 won't be triggered unless you attempt to run the exported
> > function (or you use a builtin such as declare or type that must print
> > the code, things like type -t are safe to use).
>
> Even with this?
>
> type='() { echo hi there; }' bash
>
> (Or the added stuff from Florian's patch).


This patch doesn't remove the exportable functions feature. Thus, it is
a priori unsafe to run any command using an identifier which can be set
in the environment by an attacker*

I mentioned that `type -p' was safe meaning "not triggering the parsing
of the name passed as argument", as I expected that a careful script
might be running type -p on untrusted variables before doing something
with them. And indeed it is safe… if they use the real 'type' builtin.



> I got myself into a right old mess by redefining declare, typeset, unset
> and command.

Given that builtins have precedence over builtins, you can get trapped
very hard. You can't use builtin, unset, set, declare, eval…


IMHO, the best a script can do to protect itself (and only after patch
25 restricts the names of exported functions) is:


> if [ "$1" != "--environment-cleaned" ]; then
>  /usr/bin/env -i "$0" --environment-cleaned "$@"
> else
>  shift
>  <do things>
> fi


Assuming that env(1) is on /usr/bin/env (it's /bin/env on some unix),
argv[0] is the real script name, and it has +x (instead of needing to be
passed as an argument to the shell).

Best regards


* Or conversely, it is unsafe to let an attacker set an environment
variable matching a command name later used without sanitization.