CVE-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"
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
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 bash-3.2-24.el5
On RedHat 6 (and CentOS 6), I had the following bash version before the fix:
# rpm -qa | grep bash bash-4.1.2-3.el6.x86_64
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 bash-3.2-33.el5_11.4
On RedHat 6 (and CentOS 6), the following is the bash version after the update, which fixed the vulnerability.
# rpm -qa | grep bash bash-4.1.2-15.el6_5.2.x86_64
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'
test
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
date
cat: /tmp/echo: No such file or directory
Additional Information
- Details about CVE-2014-6271, CVE-2014-7169 from RedHat Website
- RedHat (CentOS, Fedora) Bugzilla report for CVE-2014-6271
- RedHat (CentOS, Fedora) Bugzilla report for CVE-2014-7169
- Oracle Security Alert for CVE-2014-7169 – For Solaris or Oracle Enterprise Linux
- Ubuntu CVE-2014-7169
- Debian CVE-2014-7169
My name is Ramesh Natarajan. I will be posting instruction guides, how-to, troubleshooting tips and tricks on Linux, database, hardware, security and web. My focus is to write articles that will either teach you or help you resolve a problem. Read more about
Comments on this entry are closed.
Great job boiling all this down. Particularly making sure the update works.
Nothing for Debian/Ubuntu/Mint?
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.
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 ?
For Mac OS X Mavericks, http://support.apple.com/kb/DL1769
Ramesh,
Thanks we are looking for this for timely provinding the article.
Cpher,
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.
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’
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).
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.
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?
Cheers!
Nice!
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)
done
./configure && make && make install
rm -rf /usr/src/bash43
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.
Regards,
AJ
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.
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.
And what about earlier versions of Mac Maverics ? i.e. 10.8.5 version
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
Very Nice, thanks.
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
Hi,
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
vulnerable
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.
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!!
Ramesh,
Thank you so very much. I followed instructions and it worked.
Love your site and your books.
From Brazil,
Tim
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 ?
Dear Ramesh,
Thanks for the article.
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
bash-4.1.2-14.el6.x86_64
$ 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
Thanks in advance !
Satish