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-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 5, 6, and 7, Red Hat Enterprise Linux 4 Extended Life Cycle Support, 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 alsoResolution 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:
| Product/Channel | Fixed in package | Remediation details |
|---|---|---|
| Red Hat Enterprise Linux 7 | bash-4.2.45-5.el7_0.4 | Red Hat Enterprise Linux |
| Red Hat Enterprise Linux 6 | bash-4.1.2-15.el6_5.2 | Red Hat Enterprise Linux |
| bash-4.1.2-15.el6_5.1.sjis.2 | Red Hat Enterprise Linux | |
| bash-4.1.2-9.el6_2.2 | Red Hat Enterprise Linux 6.2 AUS | |
| bash-4.1.2-15.el6_4.2 | Red Hat Enterprise Linux 6.4 EUS | |
| Red Hat Enterprise Linux 5 | bash-3.2-33.el5_11.4 | Red Hat Enterprise Linux |
| bash-3.2-33.el5_11.1.sjis.2 | Red Hat Enterprise Linux | |
| bash-3.2-24.el5_6.2 | Red Hat Enterprise Linux 5.6 LL | |
| bash-3.2-32.el5_9.3 | Red Hat Enterprise Linux 5.9 EUS | |
| Red Hat Enterprise Linux 4 | bash-3.0-27.el4.4 | Red Hat Enterprise Linux 4 ELS |
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.
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 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/
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 this update?
No, a reboot of your system or any of your services is not required. This vulnerability is in the initial import of the process environment from the kernel. This only happens when Bash is started. After the update that fixes this issue is installed, such new processes will use the new code, and will not be vulnerable. Conversely, old processes will not be started again, so the vulnerability does not materialize. If you have a strong reason to suspect that a system was compromised by this vulnerability then a system reboot should be performed after the update is installed as a best security practice and security checks should be analyzed for suspicious activity.
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.
Source : RedHat
No comments:
Post a Comment