[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1411771342.2031.5.camel@16bits.net>
Date: Sat, 27 Sep 2014 00:42:22 +0200
From: Ángel González <angel@...its.net>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Non-upstream patches for bash
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.
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.
