Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Sep 2014 19:16:20 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: chet.ramey@...e.edu
Subject: Re: 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

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ