Re: CVE-2014-6271: remote code execution through bash

[Simon McVittie <smcv () debian org>]

On 25/09/14 16:17, John Haxby wrote:
> At some stage scripts are going to break, especially if they're relying
> on command, but this whole exercise leaves me feeling uneasy.   ssh and
> sudo both restrict environment variables, but I just tried this:
>
>   $ xxx='() { echo hello; }' su
>   Password:
>   # xxx
>   hello
>
> Of course, su isn't affected, but if I drop one of these in for an
> overly-trusting admin who runs su on my terminal ...

An overly-trusting admin who runs su on your terminal is already doomed,
because the su in your $PATH could be something that prompts for a
password, captures it, stuffs it into the real su's stdin while
suppressing the password prompt, then pipes su's stdout and stdin
to/from the terminal.

But, more generally, as I said while dealing with a D-Bus- and
environment-variable-related vulnerability, I think anything that starts
in a potentially attacker-controlled environment, and escalates its
privileges, should filter the environment through a (small!) whitelist
of known-good variables before it does anything non-trivial. pkexec is
an example of a setuid executable that is on the "good list" here: if
you don't try to execute one of its few "good" variables (e.g. LANG,
TERM) as the name of a command, then you won't execute an exported
function of this type.

Unfortunately, this is not consistently done, and in particular su(8)
has not traditionally sanitized the environment in this way before
invoking PAM modules (which are a plugin architecture, hence an
unbounded attack surface).

The particularly nasty thing about CVE-2014-6271 is that the name of the
variable is not relevant when exploiting that vulnerability, only the
value, which means it will bypass many whitelists of safe variable
names. I don't think that reduces the value of filtering
attacker-supplied environments through a whitelist when not using a
version of bash that is vulnerable.

    S