oss-sec mailing list archives
Re: CVE-2014-6271: remote code execution through bash
From: Solar Designer <solar () openwall com>
Date: Wed, 24 Sep 2014 19:16:20 +0400
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
Current thread:
- CVE-2014-6271: remote code execution through bash Florian Weimer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Florian Weimer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Florian Weimer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Florian Weimer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Henri Salo (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Alexander E. Patrakov (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash gremlin (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Tim (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Rich Felker (Sep 25)
- Re: CVE-2014-6271: remote code execution through bash Florian Weimer (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash mancha (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Chet Ramey (Sep 24)
- Re: CVE-2014-6271: remote code execution through bash Solar Designer (Sep 24)