≡ Menu

How to Fix Bash Shellshock CVE-2014-6271, CVE-2014-7169 on Linux

bash promptCVE-2014-6271 is a high impact critical fix. If you are running a Linux system, you should fix this vulnerability.

This CVE-2014-6271 (and CVE-2014-7169) vulnerability is also called as Shellshock.

A flaw was found in the way Bash evaluated certain specially crafted environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.

Using bash shell, this vulnerability allows an attacker to execute random shell commands on your environment. The idea behind this is an attacker can bypass the environment variable restriction, which allows him to execute shell commands.

Please note that some services (or application) that are running on Linux servers might allow unauthenticated attackers to specify some environment variables, which will in-turn allow them to exploit this vulnerability over the network without any authentication.

All you have to do to fix this is to upgrade your bash to the latest version. For example, on RedHat or CentOS, do the following to fix this issue:

yum update bash

Is your System Vulnerable to CVE-2014-6271?

RedHat has provided the following script to test whether your system is vulnerable or not.

If you see the word “vulnerable” in the output, then your system is vulnerable.

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

Please note that you might also see some error message along with with the word “vulnerable” in the output. For example, the following is the output on a RedHat 5 and RedHat 6 (and CentOS 5 and 6) system that is vulnerable.

# env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
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'

Bash Version Before the Fix

Before fixing the issue, check your current bash version. On RedHat 5 (and CentOS 5), I had the following bash version before the fix:

# rpm -qa | grep bash

On RedHat 6 (and CentOS 6), I had the following bash version before the fix:

# rpm -qa | grep bash

Fix the CVE-2014-6271

Now, update the bash using yum (or other package management utility for your appropriate distribution)

yum update bash

On RedHat 5 (and CentOS 5), the following is the bash version after the update, which fixed the vulnerability.

# rpm -qa | grep bash

On RedHat 6 (and CentOS 6), the following is the bash version after the update, which fixed the vulnerability.

# rpm -qa | grep bash

Test the CVE-2014-6271 Vulnerability after the fix

After the bash is upgraded to the latest version, when you execute the test, you’ll not see the word “vulnerable” in the following command output. Please note that the warning and the error message shown below is Ok.

# 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'

What about CVE-2014-7169?

After the initial fix was released, redhat found out that the CVE-2014-6271 fix was incomplete, and bash still allowed few characters that can be put in the environment variable under some special circumstances.

When you did the yum update bash from the previous step, it will automatically get the latest version of bash, which also includes the fix for CVE-2014-7169. So, you really don’t have to do anything specific for this fix.

However, you can still test to make sure your system is not vulnerable to this issue by executing the following on your system:

cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo

On a system that is vulnerable to CVE-2014-7169, you’ll notice that the following created the file /tmp/echo, and it will display the content of the file.

If you see the following output, you should update your bash to latest version using “yum update bash” (or use appropriate package management utility for your distro)

# 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 16:15:09 PDT 2014

If you system is not vulnerable to CVE-2014-7169, you’ll see the following output, which will not create the /tmp/echo file.

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

Additional Information

If you enjoyed this article, you might also like..

  1. 50 Linux Sysadmin Tutorials
  2. 50 Most Frequently Used Linux Commands (With Examples)
  3. Top 25 Best Linux Performance Monitoring and Debugging Tools
  4. Mommy, I found it! – 15 Practical Linux Find Command Examples
  5. Linux 101 Hacks 2nd Edition eBook Linux 101 Hacks Book

Bash 101 Hacks Book Sed and Awk 101 Hacks Book Nagios Core 3 Book Vim 101 Hacks Book

{ 25 comments… add one }

  • Douglas September 29, 2014, 12:51 pm

    Great job boiling all this down. Particularly making sure the update works.

  • cipher September 29, 2014, 12:57 pm

    Nothing for Debian/Ubuntu/Mint?

  • Jose Damian September 29, 2014, 3:52 pm

    Cool. I already fixed it in Centos, but with my Debian I couldnt make it. I executed apt-get dist-upgrade, but the test was still positive.

  • Tex September 29, 2014, 4:37 pm

    I fixed most of my servers, but on of my Centos (5.4) tells me “Package(s) bash available, but not installed.”, and he obviously is … Any idea how to work around that ?

  • Meng Lu September 30, 2014, 12:17 am

    For Mac OS X Mavericks, http://support.apple.com/kb/DL1769

  • Bhagyaraj September 30, 2014, 12:24 am

    Thanks we are looking for this for timely provinding the article.

    Seems bash shell which got from Free Software Foundation effected to all versions of Linux.

    #bash –version
    GNU bash, version 3.2.51(1)-release (x86_64-suse-linux-gnu)
    Copyright (C) 2007 Free Software Foundation, Inc.

  • tariq September 30, 2014, 12:53 am

    this is how you can fix it on Debian distro’s

    env x='() { :;}; echo you_system_is_vulnerable’ bash -c ‘echo yes_it_is’ ( TO TEST )

    echo “deb http://ftp.us.debian.org/debian squeeze-lts main non-free contrib” >> /etc/apt/sources.list && apt-get update && apt-get install –only-upgrade bash

    test again using env x='() { :;}; echo you_system_is_vulnerable’ bash -c ‘echo yes_it_is’

  • Pier September 30, 2014, 1:13 am

    According to the official com this is not a full fix (sorry I don’t have time to give you my sources, but I am sure you will find it).

  • I_Like_Or_Not September 30, 2014, 1:56 am

    This is great article.
    It is very important to update system if critical flow is found, and to do it fast, so that thing is not being exploited any more.
    There are more of those thing for sure, but somehow they do not get noticed right a way.

  • milke September 30, 2014, 7:24 am

    It’s nice you mentioned to use package manager to update the software (which peope usually do anyway), but what to do when there’s no such option, for example in environments that are not on the internet, or for servers that are outdated and don’t have software support any more? Can you describe a way to manually patch /bin/bash to protect against this specific bug?


  • Luop September 30, 2014, 8:52 am


  • Filip September 30, 2014, 9:17 am

    People who run EOL-ed distributions, can update their Bash form source

    mkdir -p /usr/src/bash43 && cd $_
    wget -q -O – http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz | tar -xzf – –strip 1 -C /usr/src/bash43
    for num in {1..27}; do
    wget -q “http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$(printf ‘%03d’ $num)”
    patch -p0 -i bash43-$(printf ‘%03d’ $num)
    ./configure && make && make install
    rm -rf /usr/src/bash43

  • AJ September 30, 2014, 12:58 pm

    Followed your steps as outlined above. Ran the script and found that I was vulnerable, running bash-4.2.47-3.fc20.i686. Updated bash via Yum and re-ran the script; I am not longer vulnerable. Even ran the final script and it did not create the temp file. Thank you very much for this information.


  • Duane September 30, 2014, 8:24 pm

    Nice article on testing for the vulnerability. I was able to confirm that my Slackware 14.1 systems have been patched successfully. I was also able to find that my Amazon EC2 micro instances had not, but a quick “sudo yum update bash” solved that problem on them.

  • By_The_Way October 1, 2014, 7:11 am

    It might be good idea not to use your real name when you post things about your system. That information might be used for bad exploits, also I have seen people posting pictures of their servers and some things that could be useful for bad guys.
    Big no no no!

    Yes, now you have sites that will snoope some other site and present that data to other people. I am not 100% sure this is good idea to.

  • Eduardo Heredia October 1, 2014, 9:53 am

    And what about earlier versions of Mac Maverics ? i.e. 10.8.5 version

  • Jetchisel October 1, 2014, 5:21 pm

    A note on the rpm query

    rpm -qa | grep bash

    prints more than just bash at least in my system.
    Also rpm can query packages by name just fine without the overhead of grep.

    rpm -qa bash

  • Selvam October 1, 2014, 6:50 pm

    Very Nice, thanks.

  • ben-Nabiy October 1, 2014, 6:51 pm

    Correction to the above post regarding manual patch.

    I would recommend downloading the main bash source, and then visiting the site to see how many patches are in there, and then update your code to:

    for num in {1..28}; do
    (replace 28 with highest number patch)

    Also, for those who just copy and paste from this site, you might generate false negatives because many terminals will copy typographers quotes (both single and double) which the shell does not understand, so will not even run the code. This is true of both the tests, as well as the commands to download source and manually compile.

    Just a little FYI

  • Steven October 1, 2014, 11:17 pm

    I just ran this command in my bash shell and it returned vulnerable.
    steven-ubuntu-desktop:~: $ env x='() { echo vulnerable;}’ x
    env: x: No such file or directory
    steven-ubuntu-desktop:~: ret:127$ env x='() { echo vulnerable;}’ bash -c x
    steven-ubuntu-desktop:~: $
    it is only a problem if you execute the value of the environment variable. I am sure I was told at University to validate all your inputs before you use them.
    Also the hacker will have to obtain access to the shell and get root privliage to do any damage.

  • Virneto October 2, 2014, 5:21 am

    That’s Great. I always love the way you presente things. Actually I’ve waited for you to address this to solve my server as I’ve had already checked it (CentOs) was vulnerable!
    Thanks a million!
    Chees to you!!

  • Timothy October 2, 2014, 5:56 am

    Thank you so very much. I followed instructions and it worked.
    Love your site and your books.
    From Brazil,

  • Renan October 3, 2014, 11:06 am

    I’m using Ubuntu 11.10 but after I run the apt-get update and apt-get upgrade bash, it says “bash is already the newest version” and the problem still occurs.

    Anyone can help ?

  • Agnel James October 7, 2014, 1:44 am

    Dear Ramesh,

    Thanks for the article.

  • Satish V October 8, 2014, 9:20 pm

    Hi Ramesh,

    From the output of the rpm query command i could see that one of my managed system is already running the latest bash but the system seems to be vulnerable.

    $ rpm -qa | grep bash

    $ env ‘x=() { :;}; echo vulnerable’ ‘BASH_FUNC_x()=() { :;}; echo vulnerable’ bash -c “echo test”
    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’

    Thanks in advance !


Leave a Comment