// Tutorial //

How to Protect Your Server Against the Shellshock Bash Vulnerability

Published on September 25, 2014
Default avatar
By Mitchell Anicas
Developer and author at DigitalOcean.
How to Protect Your Server Against the Shellshock Bash Vulnerability

Introduction

On September 24, 2014, a GNU Bash vulnerability, referred to as Shellshock or the “Bash Bug”, was disclosed. In short, the vulnerability allows remote attackers to execute arbitrary code given certain conditions, by passing strings of code following environment variable assignments. Because of Bash’s ubiquitous status amongst Linux, BSD, and Mac OS X distributions, many computers are vulnerable to Shellshock; all unpatched Bash versions between 1.14 through 4.3 (i.e. all releases until now) are at risk.

The Shellshock vulnerability can be exploited on systems that are running Services or applications that allow unauthorized remote users to assign Bash environment variables. Examples of exploitable systems include the following:

  • Apache HTTP Servers that use CGI scripts (via mod_cgi and mod_cgid) that are written in Bash or launch to Bash subshells
  • Certain DHCP clients
  • OpenSSH servers that use the ForceCommand capability
  • Various network-exposed services that use Bash

A detailed description of the bug can be found at CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, and CVE-2014-7187.

Because the Shellshock vulnerability is very widespread–even more so than the OpenSSL Heartbleed bug–and particularly easy to exploit, it is highly recommended that affected systems are properly updated to fix or mitigate the vulnerability as soon as possible. We will show you how to test if your machines are vulnerable and, if they are, how to update Bash to remove the vulnerability.

Check System Vulnerability

On each of your systems that run Bash, you may check for Shellshock vulnerability by running the following command at the bash prompt:

env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

The highlighted echo Bash is vulnerable! portion of the command represents where a remote attacker could inject malicious code; arbitrary code following a function definition within an environment variable assignment. Therefore, if you see the following output, your version of Bash is vulnerable and should be updated:

Bash is vulnerable!
Bash Test

If your output does not include the simulated attacker’s payload, i.e. “Bash is vulnerable” is not printed as output, you are protected against at least the first vulnerability (CVE-2014-6271), but you may be vulnerable to the other CVEs that were discovered later. If there are any bash warnings or errors in the output, you should update Bash to its latest version; this process is described in the next section.

If the only thing that is output from the test command is the following, your Bash is safe from Shellshock:

Bash Test

Test Remote Sites

If you simply want to test if websites or specific CGI scripts are vulnerable, use this link: ‘ShellShock’ Bash Vulnerability CVE-2014-6271 Test Tool.

Simply enter the URL of the website or CGI script you want to test in the appropriate form and submit.

Fix Vulnerability: Update Bash

The easiest way to fix the vulnerability is to use your default package manager to update the version of Bash. The following subsections cover updating Bash on various Linux distributions, including Ubuntu, Debian, CentOS, Red Hat, and Fedora.

APT-GET: Ubuntu / Debian

For currently supported versions of Ubuntu or Debian, update Bash to the latest version available via apt-get:

sudo apt-get update && sudo apt-get install --only-upgrade bash

Now check your system vulnerability again by running the command in the previous section (Check System Vulnerability).

End of Life Ubuntu / Debian Releases

If you are running a release of Ubuntu / Debian that is considered end of life status, you will have to upgrade to a supported to use the package manager to update Bash. The following command can be used to upgrade to a new release (it is recommended that you back up your server and important data first, in case you run into any issues):

sudo do-release-upgrade

After the upgrade is complete, ensure that you update Bash.

YUM: CentOS / Red Hat / Fedora

Update Bash to the latest version available via yum:

sudo yum update bash

Now check your system vulnerability again by running the command in the previous section (Check System Vulnerability).

End of Life CentOS / Red Hat / Fedora Releases

If you are running a release of CentOS / Red Hat / Fedora that is considered end of life status, you will have to upgrade to a supported to use the package manager to update Bash. The following command can be used to upgrade to a new release (it is recommended that you back up your server and important data first, in case you run into any issues):

sudo yum update

After the upgrade is complete, ensure that you update Bash.

Conclusion

Be sure to update all of your affected servers to the latest version of Bash! Also, be sure to keep your servers up to date with the latest security updates!


Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in our Questions & Answers section, find tutorials and tools that will help you grow as a developer and scale your project or business, and subscribe to topics of interest.

Sign up
About the authors
Default avatar
Developer and author at DigitalOcean.

Still looking for an answer?

Was this helpful?
10 Comments

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

if you have some old / EOL release, this code may help you.

it requires you to have a compiler, patch & make, as such you may need to install these packages

for Ubuntu you can do

for CentOS/variants

(you may uninstall them afterwards if you no longer need)

after that, you can install bash from scratch, follow these commands (taken from the internet somewhere)

can first “cd /tmp” or start in any directory of your choice; must be executed as root [updated 2014-09-27 0900 EST [GMT-0500] now 26 patches instead of 25] [updated 2014-09-28 0900 EST [GMT-0500] now 27] [updated 2014-10-01 1400 EST [GMT-0500] now 28] [updated 2014-10-02 2300 EST [GMT-0500] now 29]

mkdir src
cd src
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 0 30); do wget     http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz 
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 0 30);do patch -p0 < ../bash43-$i; done
#build and install
./configure && make && make install
cd .. 
cd ..
rm -r src

after this you should have the newest bash installed on your system

run the test again to check yourself

env VAR='() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

you should be good to go now!

Here’s Puppet code to patch it on CentOS:

exec { 'patch_shellshock_security_hole':
  command => "/usr/bin/yes | /usr/bin/yum update bash; touch /root/shellshock_bug_has_been_patched",
  creates => '/root/shellshock_bug_has_been_patched',
}

I have just tested this code and it worked fine on CentOS 6.4.

Ross

Not so fast! Give it a try, still vulnerable!

env -i X=' () { }; echo hello' bash -c 'date'

https://shellshocker.net/

Thanks Mitchel

I will have to tell the admin to be careful and follow what the monitoring tool Anturis says and alerts. By the way, are ny monitoring tool at help here?

All people running Linux systems whether on local machines or servers were put in panic when a security flaw was discoverd in Bash, the Bash Remote Exploit was nick named as Shellshock.

The vulnerability was exposed in HTTP/CHI scripts and in OpenSSH. It effected nearly all versions of Linux, thankfully there was an update available to secure yourself.

Cloudways was among the first to fix the entire infrastructure and provide extra security to its clients - Here: Bash Remote Exploits

FYI - I’ve a droplet from a DO supplied application “WordPress on Ubuntu12.10” . The Control Panel Kernel screen says “Orginal Kernel (Ubuntu 12.10 x64 vmlinuz-3.5.0-17-generic(25))” uname –ri lists - 3.5.0-17-generic x86_64 (only one option)

I tried the suggestion in this article, and they didn’t work. I tried a whole bunch of other suggestions that other people have put out there using mirrors supplied by DO - and they didn’t work I tried a Kernel Upgrade - and it turns out that for my DO supplied Ubuntu12.10 distribution it is some strange version (created as a DO application) and it isn’t supported in the Kernel Upgrade - despite there being a lot of options visually available in the Control Panel - Kernel Upgrade. I’ve opened a ticket on the upgrade question, and I’m not getting any reasonable suggestions - it seems DO support is talking Apple Pie - “you need to upgrade” but no reasonable working ways to do it, “Changing the kernel in the control panel does not upgrade the kernel on the droplet.” - with no workable method for what can work.

I’m getting DO advice that aren’t working solutions.

I’ve found such tool for vulneratility test: http://www.host-tracker.com/Blog/Shellshock

after i installed the bash update, my php shell_exec command to run pdftk does not work anymre - any ideas what to do?

thanks

Thanks for the tutorial, I’m not a regular sysadmin and only fine tune DO droplets when the need arises and then its usually a steep learning curve. I did a backup - the node is 198.199.94.20 Way back I launched a defined DO package for wordpress - my console settings Kernel says “Original Kernel (Ubuntu 12.10 x64 Server vmlinuz-3.5.0.17-generic(25))" I’ve tried to swap the kernel out for one of the options “Ubuntu 13.10 x64 vmlinuz-3.11.0-26-generic” to then do an upgrade but after rebooting it is still at 12.10? I’m wondering why this failed?

I’ve tried using the “do-release-upgrade” - but it comes back with

Your Ubuntu release is not supported anymore. Err Upgrade tool signature 404 Not Found [IP: 91.189.91.14 80] Err Upgrade tool 404 Not Found [IP: 91.189.91.14 80] Fetched 0 B in 0s (0 B/s) WARNING:root:file ‘raring.tar.gz.gpg’ missing Failed to fetch Fetching the upgrade failed. There may be a network problem.

I’ve tried https://www.digitalocean.com/community/questions/update-on-ubuntu-12-10-server-failing-not-found but it aborted and restored back to 12.10

I hear “@manicas” advice that its not recommended to let a server be at 12.10 - but I do have a DO supplied configuration that is at 12.10, and I wonder is there a tutorial for dummies to say how to upgrade it. I have spent a couple of hours trying to stitch together an upgrade. Many thanks.