BASH Shell Code Injection Vulnerability & Remediation for RHEL Users

You may have recently heard the news on Bash Shell Code Injection could potentially be bigger than ‘Heartbleed’. The Department of Homeland Security’s United States Computer Emergency Readiness Team, or US-CERT, issued an alert saying the vulnerability affected Unix-based operating systems including Linux and Apple Inc’s <AAPL.O> Mac OS X.  RHEL users need to be aware of a vulnerability since it affects all versions of the Bash package shipped with Red Hat Enterprise Linux.  Since many of Red Hat’s products run on a base installation of Red Hat Enterprise Linux, there is a risk of other products being impacted by this vulnerability as well.

 

The Bash Code Injection Vulnerability CVE-2014-6271 could allow for arbitrary code execution, allowing an attacker to bypass imposed environment restrictions. Certain services and applications allow remote unauthenticated attackers to exploit this vulnerability by providing environment variables. As the Bash shell is the most commonly used shell today, the risk of impact from this vulnerability if left unchecked could be severe.

 

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. See also Resolution for Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271) in Red Hat Enterprise Linux. Red Hat is working on patches in conjunction with the upstream developers as a critical priority.

 

Shadow-Soft and Red Hat advise customers to upgrade to the version of Bash which contains the fix for CVE-2014-6271, and not wait for the patch which fixes CVE-2014-7169. CVE-2014-7169 is a less severe issue and patches for it are being worked on.

 

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.

 

Applications which directly create bash functions as environment variables need to be made aware of the new name mangling. Previously, a function “compute” had to be stored in an environment variable of the same name. Now it has to use the name “BASH_FUNC_compute()”. As a result, there are now two pairs of parenthesis in the environment string, as in “BASH_FUNC_compute()=() {“.

 

Functions written in bash do not need changing, even if they are exported with “export -f”. Bash will transparently apply the 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 shipped in Red Hat Enterprise Linux.

 

Products Affected:

Product/ChannelFixed in packageRemediation details
Red Hat Enterprise Linux 7bash-4.2.45-5.el7_0.2Red Hat Enterprise Linux
Red Hat Enterprise Linux 6bash-4.1.2-15.el6_5.1Red Hat Enterprise Linux
bash-4.1.2-15.el6_5.1.sjis.1Red Hat Enterprise Linux
bash-4.1.2-9.el6_2.1Red Hat Enterprise Linux 6.2 AUS
bash-4.1.2-15.el6_4.1Red Hat Enterprise Linux 6.4 EUS
Red Hat Enterprise Linux 5bash-3.2-33.el5.1Red Hat Enterprise Linux
bash-3.2-33.el5_11.1.sjis.1Red Hat Enterprise Linux
bash-3.2-24.el5_6.1Red Hat Enterprise Linux 5.6 LL
bash-3.2-32.el5_9.2Red Hat Enterprise Linux 5.9 EUS
Red Hat Enterprise Linux 4bash-3.0-27.el4.2Red 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.

PackageDescription
httpdCGI 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.
dhclientThe 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.
CUPSIt is believed that CUPS is affected by this issue. Various user supplied values are stored in environment variables when cups filters are executed.
sudoCommands 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.
FirefoxWe 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.
PostfixThe 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.

 

 

 

FAQ’s

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?

 

 

Contact Shadow-Soft or Open a support case with Red Hat.

 

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 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. They could not reproduce the behavior seen in Bash. If similar issues are discovered in other shells Red Hat 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 the above workarounds, we strongly recommend to apply the security advisory which fixes this issue

 

If you have questions or concerns, please contact Shadow-Soft.

 

Sincerely,

 

The Shadow-Soft Security Team