How to Fix the ‘Shell Shock’ bash Vulnerability in Linux

Share this Article :

Q. Linux system administrators who maintaining the servers that are exposed to the Internet should be the most concerned about this Shell Shock’ bash Vulnerability or attack. Most of the patches are now available from the vendors that should close this security hole. For those who still haven’t check your linux system, below are the recommended unofficial procedure in order to ensure you server are not vulnerable from Shellshock attack.

A. Follow the following procedure to secure you system.

1. As a root, login to your linux system and run the following command :

[[email protected] ~]# env x='() { :ignored function;}; echo vulnerable' bash

2. Skip the next step if you command did not say vulnerable, meaning your bash is up to date.

If you see the return message below, kindly proceed to next steps.
Example :

[[email protected] ~]# env x='() { :ignored function;}; echo vulnerable' bash

3. Perform update for bash :

[[email protected] ~]# yum update bash -y

4. Check your current bash version. If in CentOS 7 or RHEL 7 the fix is in bash-4.2.45 :

[[email protected] ~]# rpm -qa | grep bash

Please take a look of below details from redhat article.

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.

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

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:

Leave a Reply