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.

Update: 2014-09-30 18:00 UTC

Two new flaws have been reported that are mitigated by the currently available Bash packages. Please refer to the FAQ for further information.

Update: 2014-09-29 05:00 UTC

Malware is circulating that exploits this vulnerability. For more details, see this article.

Update: 2014-09-26 05:15 UTC

Red Hat has become aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169.

Updated bash packages that address CVE-2014-7169 are now available for Red Hat Enterprise Linux 4, 5, 6, and 7, Red Hat Enterprise Linux 5.6 Long Life, Red Hat Enterprise Linux 5.9 Extended Update Support, Red Hat Enterprise Linux 6.2 Advanced Update Support, and Red Hat Enterprise Linux 6.4 Extended Update Support, and Shift_JIS for Red Hat Enterprise Linux 5 and 6. See also Resolution for Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169) in Red Hat Enterprise Linux.

Diagnostic Steps

Red Hat Access Labs has provided a script to help confirm if a system is patched against to the Shellshock vulnerability. You can also manually test your version of Bash by running the following command:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

If the output of the above command contains a line containing only the word vulnerable 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.

Note that different Bash versions will also print different warnings while executing the above command. The Bash versions without any fix produce the following output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

The versions with only the original CVE-2014-6271 fix applied produce the following output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

The versions with additional fixes from RHSA-2014:1306, RHSA-2014:1311 and RHSA-2014:1312 produce the following output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

The difference in the output is caused by additional function processing changes explained in the "How does this impact systems" section below.

The fix for CVE-2014-7169 ensures that the system is protected from the file creation issue. To test if your version of Bash is vulnerable to CVE-2014-7169, run the following command:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

If your system is vulnerable, the time and date information will be output on the screen and a file called /tmp/echo will be created.

If your system is not vulnerable, you will see output similar to:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory

If your system is vulnerable, you can fix these issues by updating to the most recent version of the Bash package by running the following command:

# yum update bash

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.

The patch for CVE-2014-7169 introduces changes to how Bash evaluates environment variables. Applications which directly create Bash functions as environment variables need to be made aware of these changes. Previously, a function had to be stored in an environment variable of the same name. For example, the function "compute" would be stored in an environment variable named "compute". With the patch for CVE-2014-7169 applied, it would need to use the name "BASH_FUNC_compute()". As a result, there are now two pairs of parentheses in the environment string, as in "BASH_FUNC_compute()=() { }".

Functions written in Bash itself do not need to be changed, even if they are exported with "export -f". Bash will transparently apply the appropriate naming when exporting, and reverse the process when importing function definitions.

Services that create such environment variables will need to be restarted to work with the new version of Bash. This behavior is not used by any of the packages provided in any version of Red Hat Enterprise Linux.

Products Affected:

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.

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.

Some additional information regarding CVE-2014-6271 and CVE-2014-7169 is available at: https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/

Some additional information regarding customers who have RHEL 4 Standard or Premium Entitlements, but not ELS, is available at https://access.redhat.com/discussions/1211573

The original flaw in Bash was assigned CVE-2014-6271. Shortly after this issue went public, a researcher found a similar flaw that was not blocked by the first fix and this was assigned CVE-2014-7169. Later, Red Hat Product Security researcher Florian Weimer found additional problems and they were assigned CVE-2014-7186 and CVE-2014-7187. Recently, two more flaws were reported, although the details of these flaws are currently non-public, and they were assigned CVE-2014-6277 and CVE-2014-6278. The first four flaws have been fixed in the latest Bash packages currently available, and the last two flaws are mitigated by the same. As of this writing (2014-09-30) there are currently no known security flaws that these Bash packages are vulnerable to. Please refer to the actual CVE pages noted for the latest statements on these flaws.

I believe my system may have been compromised due to this vulnerability, what should I do?

If you have run the diagnostic steps in this article, and your system still appears to be vulnerable, or you believe your system has been compromised, open a support case with Red Hat or contact Red Hat support by phone.

Do I need to reboot or restart services after installing the update for CVE-2014-6271 and CVE-2014-7169?

If your system uses exported Bash functions, restarting affected services is recommended. Affected interactive users may have to re-login, and screen or tmux sessions may need to be restarted.

The Bash update provided to fix these issues changes the names of exported functions in the environment. If a function is exported by the old version of Bash, it is not recognized by newly started Bash processes after the update, and essentially becomes undefined. Restarting the services ensures that the new version of Bash exports functions under the expected name, making it visible again.

To find out which services need to be restarted (or which users have to re-login), execute the following command after updating:

$ grep -l -z '[^)]=() {' /proc/[1-9]*/environ | cut -d/ -f3

The returned PIDs belong to processes which are using the old exported function definitions in their environment. These processes must be restarted. To discover which service started a certain PID and needs restarting, on Red Hat Enterprise Linux 7, use the following command:

$ systemctl status <PID>

On Red Hat Enterprise Linux 6 and earlier, use the pstree -p or ps -axuf command and look for a particular PID.

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?

Please see Mitigating the shellshock vulnerability (CVE-2014-6271 and CVE-2014-7169) for details on potential mitigations if you are unable to install the updated packages. The best mitigation is to install the latest available packages (noted above) as they currently protect against all reported vulnerabilities.

The following Red Hat websites, which provide services to customers have been confirmed to be updated:

• www.redhat.com
• access.redhat.com (Red Hat Customer Portal)
• rhn.redhat.com (Red Hat Network)

Red Hat utilises Salesforce to deliver services to customers. Salesforce have released a statement that it has determined Salesforce services are not vulnerable to this issue.

Red Hat has observed unsuccessful attempts to exploit this vulnerability against the above websites. We continue to monitor our systems to ensure their confidentiality, integrity and availability.