Re: [oss-security] CVE-2014-6271: remote code execution through bash

On Wed, Sep 24, 2014 at 04:05:51PM +0200, Florian Weimer wrote:
> Stephane Chazelas discovered a vulnerability in bash, related to how
> environment variables are processed: trailing code in function
> definitions was executed, independent of the variable name.
>
> In many common configurations, this vulnerability is exploitable over
> the network.
>
> Chet Ramey, the GNU bash upstream maintainer, will soon release
> official upstream patches.

More detail is already out:

https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html

Florian posted a Debian security advisory on this ([DSA 3032-1] bash
security update) to the debian-security-announce list, but somehow it is
not yet seen at:

https://www.debian.org/security/
https://lists.debian.org/debian-security-announce/2014/

(I guess it will be very soon.)

I've just confirmed that the issue can be exploited via OpenSSH setting
SSH_ORIGINAL_COMMAND:

$ ssh -o 'rsaauthentication yes' 0 '() { ignored; }; /usr/bin/id'
uid=500(sandbox) gid=500(sandbox) groups=500(sandbox)
Received disconnect from 127.0.0.1: Command terminated on signal 11.

This is with command="set" in .ssh/authorized_keys for the key being
used. (Without the "; /usr/bin/id" portion, the command prints the
environment variables, including SSH_ORIGINAL_COMMAND being the function
with just "ignored" in its body.) As we can see, the command runs, and
moreover in this case bash happened to segfault after having run "id".

I see no good workaround. Starting the forced command with "unset
SSH_ORIGINAL_COMMAND &&" does not help - we'd need to unset the variable
before starting bash, not from bash.

TERM is another attack vector, but IIRC sshd does not set TERM when
no-pty is used. So, speaking of SSH forced commands, it appears to be
only SSH_ORIGINAL_COMMAND that we have no good workaround for.

Indeed, there are many other setups where the problem is exploitable,
not just SSH forced commands.

Alexander