https://access.redhat.com/articles/1200223
Red Hat has been made aware of a vulnerability affecting all versions of the bash package as shipped with Red Hat products. This vulnerability CVE-2014-6271 could allow for arbitrary code execution. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.
How does this impact systems
This issue affects all products which use the Bash shell and parse values of environment variables. This issue is especially dangerous as there are many possible ways Bash can be called by an application. Quite often if an application executes another binary, Bash is invoked to accomplish this. Because of the pervasive use of the Bash shell, this issue is quite serious and should be treated as such.
All versions prior to those listed as updates for this issue are vulnerable to some degree.
See the appropriate remediation article for specifics.
Products Affected:
Product/Channel Fixed in package Remediation details
Red Hat Enterprise Linux 7 bash-4.2.45-5.el7_0.2 Red Hat Enterprise Linux
Red Hat Enterprise Linux 6 bash-4.1.2-15.el6_5.1 Red Hat Enterprise Linux
bash-4.1.2-15.el6_5.1.sjis.1 Red Hat Enterprise Linux
bash-4.1.2-9.el6_2.1 Red Hat Enterprise Linux 6.2 AUS
bash-4.1.2-15.el6_4.1 Red Hat Enterprise Linux 6.4 EUS
Red Hat Enterprise Linux 5 bash-3.2-33.el5.1 Red Hat Enterprise Linux
bash-3.2-33.el5_11.1.sjis.1 Red Hat Enterprise Linux
bash-3.2-24.el5_6.1 Red Hat Enterprise Linux 5.6 LL
bash-3.2-32.el5_9.2 Red Hat Enterprise Linux 5.9 EUS
Red Hat Enterprise Linux 4 bash-3.0-27.el4.2 Red Hat Enterprise Linux 4 ELS
Since any machine in the product classes listed above cannot determine whether a connection it makes as a client is to a vulnerable server the only prudent solution is to ensure that any machine running a vulnerable version is updated.
Diagnostic Steps
To test if your version of Bash is vulnerable to this issue, run the following command:
$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
If the output of the above command looks as follows:
vulnerable
this is a test
you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, 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
Common Configuration Examples:
Red Hat performed an analysis to better understand the magnitude of this issue and how it affects various configurations. The below list is not exhaustive, but is meant to give some examples of how this issue affects certain configurations, and why the high level of complexity makes it impossible to specify something is not affected by this issue. The best course of action is to upgrade Bash to a fixed version.
Package Description
httpd CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.
Secure Shell (SSH) It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.
dhclient The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.
CUPS It is believed that CUPS is affected by this issue. Various user supplied values are stored in environment variables when cups filters are executed.
sudo Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.
Firefox We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.
Postfix The Postfix server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.
A more detailed analysis of the flaw is available at: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack
Frequently Asked Questions
This FAQ is for the vulnerability CVE-2014-6271 in Bash.
I believe my system may have been compromised due to this vulnerability, what should I do?
Open a support case with Red Hat ( https://access.redhat.com/support/cases/new ) or Contact Red Hat support by phone ( https://access.redhat.com/support/contact/technicalSupport ).
Do I need to reboot or restart services after installing this update?
No, once the new bash package is installed, you do not need to reboot or restart any services. This issue only affects the Bash shell during startup, not already running shells. Upgrading the package will ensure all new shells that are started are using the fixed version.
Are other shells vulnerable to this issue?
Red Hat has tested other shells for this issue. We could not reproduce the behavior seen in Bash. If similar issues are discovered in other shells we will release updates as appropriate.
Are there any possible mitigations against this issue?
Workaround: Using mod_security:
The following mod_security rules can be used to reject HTTP requests containing data that may be interpreted by Bash as function definition if set in its environment. They can be used to block attacks against web services, such as attacks against CGI applications outlined above.
Request Header values:
SecRule REQUEST_HEADERS “^\(\) {” “phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”
SERVER_PROTOCOL values:
SecRule REQUEST_LINE “\(\) {” “phase:1,deny,id:1000001,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”
GET/POST names:
SecRule ARGS_NAMES “^\(\) {” “phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”
GET/POST values:
SecRule ARGS “^\(\) {” “phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”
File names for uploads:
SecRule FILES_NAMES “^\(\) {” “phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”
These may result in false positives but it’s unlikely, and they can log them and keep an eye on it. You may also want to avoid logging as this could result in a significant amount of log files.
Workaround: Using IPTables:
A note on using IPTables string matching:
iptables using -m string –hex-string ‘|28 29 20 7B|’
Is not a good option because the attacker can easily send one or two characters per packet and avoid this signature easily. However, it may provide an overview of automated attempts at exploiting this vulnerability.
Note: Despite of the above workarounds, Red Hat strongly recommends to apply the security advisory which fixes this issue
How to upgrade on Redhat/CentOS:
yum clean all
yum update bash
Ubuntu/Debian:
debian squeeze users should switch to lts version:
update your sources.list:
”
deb http://ftp.ro.debian.org/debian/ squeeze-updates main
deb-src http://ftp.ro.debian.org/debian/ squeeze-updates main
deb http://http.debian.net/debian/ squeeze main contrib non-free
deb-src http://http.debian.net/debian/ squeeze main contrib non-free
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free
deb http://http.debian.net/debian squeeze-lts main contrib non-free
deb-src http://http.debian.net/debian squeeze-lts main contrib non-free
”
apt-get update
apt-get install –only-upgrade bash
compile for older unsupported distributions:
sudo apt-get install bison
sudo apt-get install texinfo
# get bash 3.2 source
mkdir src && cd src
wget http://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz
tar zxvf bash-3.2.tar.gz
cd bash-3.2
# download and apply all patches, including the latest one that patches CVE-2014-6271
for i in $(seq -f “%03g” 1 52); do
wget -nv http://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-$i
patch -p0 < bash32-$i
done
# compile and install to /usr/local/bin/bash
./configure && make
sudo make install
# point /bin/bash to the new binary
sudo mv /bin/bash /bin/bash.old
sudo ln -s /usr/local/bin/bash /bin/bash
# test by comparing the output of the following
env x='() { :;}; echo vulnerable’ /bin/bash.old -c echo
env x='() { :;}; echo vulnerable’ bash -c echo