Bash or the Bourne again shell, is a UNIX like shell, which is perhaps one of the most installed utilities on any Linux system. From its creation in 1980, bash has evolved from a simple terminal based command interpreter to many other fancy uses.
In Linux, environment variables provide a way to influence the behavior of software on the system. They typically consists of a name which has a value assigned to it. The same is true of the bash shell. It is common for a lot of programs to run bash shell in the background. It is often used to provide a shell to a remote user (via ssh, telnet, for example), provide a parser for CGI scripts (Apache, etc) or even provide limited command execution support (git, etc)
Coming back to the topic, the vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the bash shell. These variables can contain code, which gets executed as soon as the shell is invoked. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:
- ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
- Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
- PHP scripts executed with mod_php are not affected even if they spawn subshells.
- DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
- Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
- Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.
Like “real” programming languages, Bash has functions, though in a somewhat limited implementation, and it is possible to put these bash functions into environment variables. This flaw is triggered when extra code is added to the end of these function definitions (inside the enivronment variable). Something like:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
The patch used to fix this flaw, ensures that no code is allowed after the end of a bash function. So if you run the above example with the patched version of bash, you should get an output similar to:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
We believe this should not affect any backward compatibility. This would, of course, affect any scripts which try to use environment variables created in the way as described above, but doing so should be considered a bad programming practice.
Red Hat has issued security advisories that fixes this issue for Red Hat Enterprise Linux. Fedora has also shipped packages that fixes this issue.
We have additional information regarding specific Red Hat products affected by this issue that can be found at https://access.redhat.com/site/solutions/1207723
Testing for the original Vulnerability
You can determine if you are vulnerable to the original problem in CVE-2014-6271 by executing this test:
$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
helloThe above output is an example of a non-vulnerable bash version. If you see the word vulnerable in the output of that command your bash is vulnerable and you should update. Below is a vulnerable version from OS X 10.8.5:
Testing for the new Vulnerability
There has been an update to the original post and Bash 3.2.51(1) is still vulnerable to a variation of the vulnerability, defined in CVE-2014-7169
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Thu 25 Sep 2014 08:50:18 BSTAn official patch has not yet been released but a work-in-progress patch is visible on the mailing list. Note that I (@alblue) have tested this patch and the version of Bash still appears vulnerable
System Binaries
OS X 10.9.5 (the latest stable release at the moment) ships with Bash v3.2.51:
$ bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.You can obtain and recompile Bash as follows, providing that you have Xcode installed:
$ mkdir bash-fix
$ cd bash-fix
$ curl https://opensource.apple.com/tarballs/bash/bash-92.tar.gz | tar zxf -
$ cd bash-92/bash-3.2
$ curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 | patch -p0
$ cd ..
$ xcodebuild
$ sudo cp /bin/bash /bin/bash.old
$ sudo cp /bin/sh /bin/sh.old
$ build/Release/bash --version # GNU bash, version 3.2.52(1)-release
$ build/Release/sh --version # GNU bash, version 3.2.52(1)-release
$ sudo cp build/Release/bash /bin
$ sudo cp build/Release/sh /binAfter this, the Bash version should be v3.2.52:
$ bash --version
GNU bash, version 3.2.52(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.For security, and after testing, I recommend that you chmod -x the old versions to ensure they aren’t re-used, or move them to a backup site.
$ sudo chmod a-x /bin/bash.old /bin/sh.oldHomebrew
If you’re running bash from Homebrew you can get a patched version by running:
$ brew update
$ brew upgrade bashNote that this still leaves you with a vulnerable system bash, updating the Homebrew bash is in addition to patching the system bash as described above.
After the upgrade of brew bash to 4.3 then copy the old bash to a new file and remove the old file. cp /usr/local/bin/bash /usr/local/bin/bash_old
Then create a symbolic link to the new bash 4.3 that brew installed. ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /usr/local/bin/bash
reboot and it is complete.
Macports
If you’re running bash from MacPorts, the update process below gets you a bash version 4.3.25 which has the fix for the vulnerability. This which is useful if you have changed shells to use mac ports bash to get the version 4 features.
It will not solve the issue of standard OS scripts as the have #!/bin/sh or #!/bin/bash as the first line. (This sort of issue is why macports tries not to use Apple’s supplied versions of programs as macports tends to be updated quicker e.g. it has a newer version of bash)
$ sudo port selfupdate
$ sudo port upgrade bashNote that this still leaves you with a vulnerable system bash; you need to update the MacPorts bash in addition to patching the system bash as described above.
http://seclists.org/oss-sec/2014/q3/741
Another exploit has been found?
Try:
$ env ls='() { echo vulnerable; }' /bin/bash -c ls
$ env /bin/ls='() { echo vulnerable; }' /bin/bash -c /bin/ls