142

Recently, there have been news going around regarding "CVE-2014-6271" (See USN-2362-1), which is a vulnerability in Bash. How do I know if I am affected by this, how can I fix it, and why should I care?

This is designed as a canonical answer for this vulnerability, due to its scope and severity.

nanofarad
  • 20,717
  • 18
    "how do I fix it?" -> just run your upgrade manager! Really, Ubuntu releases security updates, there's a dedicated security team. Please don't post answers about building Bash from source!; it's needlessly complicated and harder to maintain your system in the future. – gertvdijk Sep 25 '14 at 08:26
  • 5
    Plus, also the additional CVE for the incomplete fix. CVE-2014-7169 – gertvdijk Sep 25 '14 at 09:23
  • 18
    Please do post answers about building from source. Whether they should or not, some people have ancient Ubuntu servers, and building from source may be their only option. – GaryO Sep 25 '14 at 14:59
  • I notice that dash is also vulnerable! dash is the default shell /bin/sh used by cgi etc. I'm not sure if dash is based on dash but it's has the same exploit. – hookenz Sep 25 '14 at 19:42
  • 1
    @matth can you show a source, article, or demo to show that it is actually vulnerable? I've seen many articles indicating the contrary. – nanofarad Sep 25 '14 at 19:44
  • I ran the same check and it came up as vulnerable. let me check again. – hookenz Sep 25 '14 at 19:46
  • Ok so the issue is, that after the function definition it should stop parsing. But bash continues executing arbitrary commands if vulnerable. The test is this:
    env x='() { :;}; echo vulnerable' bash -c "echo this is a test" outputs "vulnerable this is a test" on my copy of dash. Ubuntu 12.04.
    – hookenz Sep 25 '14 at 19:50
  • 3
    oops, sorry I just realised I put bash instead of dash in the test. Never mind it's fine. – hookenz Sep 25 '14 at 20:04
  • 4
  • @blade19899 the new CVE has been fixed and I have already updated my answer. I'll update the question to use the better known term shellshock. – nanofarad Sep 27 '14 at 14:40
  • 1
    Note: If you use ANYTHING besides the primary update servers (Software & Updates -> Ubuntu Software -> Download From: "Server for [country]" OR "Main Server") you risk my problem. I had a faster server (discovered using the "Select Best Server" button), but one that apparently never received the FIRST update, much less the subsequent ones. – Cliff Sep 28 '14 at 09:49
  • I used this website and ran the bash script (which just runs a set of vulnerability checks on your shell). Works like a charm. https://shellshocker.net/ To fix, just update your bash to the latest. – Blairg23 May 02 '15 at 06:31

5 Answers5

126

What is Bash?

Bash is the default interactive shell in Ubuntu. When you are interfacing with the terminal (either through the terminal emulator, over a tty, or ssh), you are generally typing commands that bash will read, and execute. Even if you do not use the terminal at all, you still have Bash.

On Ubuntu, /bin/sh is not bash (it is dash). Only bash is affected by this vulnerability.

How does the exploit affect me?

Bash and the OS keep track of a set of environment variables that describe the current logged-on user, where to look for programs on the hard disk, and other such functions. By crafting an environment variable with a specific structure, an attacker might be able to execute code next time Bash starts.

The attacker can set that environment variable multiple ways:

  • Remotely connect to a service such as SSH with a specific setup such as git over ssh. As Mitre warns, the use of the sshd ForceCommand option is an attack vector. Accounts whose shell isn't bash aren't affected.
  • Tricking you into setting the environment variable.
  • Causing another program to set an environment variable to have that crafted value. For example, you might have a webserver and script that needs to set an environment variable with specific user content. Even if that script creates its own, and doesn't touch other environment variables, it's enough. A single environment variable with any name and a crafted value is enough for the exploit to succeed.
  • Other ways I have not mentioned here.

Once they set this variable, the next time bash opens for any reason, your attacker's code will be run. This is especially fearsome with sudo -s, as it spawns bash as the super-user (an administrative user rule that has full control over your computer's data and programs). Even if you only start bash as a standard user, that user's files can be deleted.

It is important to note that even if you do not use bash yourself, many programs will spawn bash by themselves as part of their operation. Even in this case, you are vulnerable. However, Ubuntu's /bin/sh is not bash, so only programs that explicitly invoke bash and not the default scripting shell are affected.

According to Mitre:

vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

Am I vulnerable?

Use dpkg to check your installed package version:

dpkg -s bash | grep Version

This will look up info on your bash package, and filter the output to only show you the version. The fixed versions are 4.3-7ubuntu1.4, 4.2-2ubuntu2.5, and 4.1-2ubuntu3.4.

For example, I see:

wlan1-loopback% dpkg -s bash | grep Version
Version: 4.3-7ubuntu1.4

and can determine that I am not vulnerable.

How do I update?

The standard update manager will offer you this update. This is a prime example of how security updates are important, no matter what OS you use or how well-maintained it is.

The USN Bulletin states that new versions have been released for Ubuntu 14.04 Trusty Tahr, 12.04 Precise Pangolin, and 10.04 Lucid Lynx. If you are not on one of these LTS versions, but are on a reasonably-recent version, you'll most likely be able to find a patched package.

First, check if you

If you are vulnerable, you should first grab the newest package lists:

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

The first command makes sure that you have the newest package list that includes the fixed version, and the second command installs the newest (fixed) version of bash.

While the bug only appears to come into play when bash is spawned, it's still a good idea to reboot immediately if feasible.

nanofarad
  • 20,717
  • 20
    Sorry, you are vulnerable. The original patch does not fix the whole problem. See https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-7169 AFAIAA, there is currently no publicly available fix. See e.g. http://people.canonical.com/~ubuntu-security/cve/pkg/bash.html – Mormegil Sep 25 '14 at 06:42
  • Care to explain this: "Remotely connect to a service such as SSH, and try to log in."? "try" as in one does not have to achieve a valid ssh login? – Rinzwind Sep 25 '14 at 10:29
  • @Rinzwind updated. – nanofarad Sep 25 '14 at 10:40
  • @hexafraction What should I do if i still have a box with Ubuntu 12.10? As this bug is very severe, can we expect Ubuntu to still provide a patched package for no longer supported releases? – Michael Härtl Sep 25 '14 at 11:03
  • @Michael as long as you have a backport repository enabled in software sources you should get a fixed version that addresses the first CVE. The second that was reported has not had a fix released yet. – nanofarad Sep 25 '14 at 11:35
  • @hexafraction Thanks. I've done that and also updated the URLs in my sources.list to point to http://old-releases.ubuntu.com/ubuntu/. Still I don't get any updates for bash. So the fix has probably not been backported yet. – Michael Härtl Sep 25 '14 at 12:37
  • 4
    @hexafraction Where do you read that 12.10 receives an update for this? I don't think so, 12.10, 13.04, 13.10 are very much End-of-Life! And also, backport repositories are not used for security updates. – gertvdijk Sep 25 '14 at 13:39
  • 2
    @hexafraction No, they don't! That's the whole point of being End-of-Life: no support at all anymore. – gertvdijk Sep 25 '14 at 13:41
  • @hexafraction do mention the CVE due to the incomplete fix in these patches (given in Mormegil's comment). This answer is incomplete without it. -1 until then. – muru Sep 25 '14 at 13:42
  • @Rinzwind The statement about ssh is invalid I think, ssh wont touch bash without first going through authentication, so the vector only exists for people who can authenticate. More info here – Iwan Aucamp Sep 25 '14 at 14:40
  • @hexafraction I'm not sure how you get from ForceCommand to "By crafting a specific login name or hostname". At the very least you should state that user must be able to authenticate. Your stated conditions might be necessary but is not sufficient. – Iwan Aucamp Sep 25 '14 at 14:43
  • I don't like it when unexplained code is published as env x='() { :;}; echo vulnerable' bash -c 'echo hello'. Can you explain what exactly this does? If not, I am not going to run it. It's like people shouting one should run rm -r ~ and that sort of stuff. – don.joey Sep 25 '14 at 14:56
  • @don.joey it simply sets the environment variable called x to the value '() { :;}; echo vulnerable'. It then invokes bash asking it to echo back the word hello. The value of x that is set is a function definition that should do nothing. However, it is crafted to try to run 'echo vulnerable' at parsing of environment at bash start-up, which just prints vulnerable to standard out. – nanofarad Sep 25 '14 at 15:00
  • Dash is doing the same thing for me. – hookenz Sep 25 '14 at 19:49
  • 1
    @MichaelHärtl If you're on Ubuntu 12.10, you can download the 12.04 version of bash from http://packages.ubuntu.com/precise/bash and install it manually. – David Sep 25 '14 at 21:37
  • Looks like 4.3-7ubuntu1.2 and other updates are out : https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages – DaveShaw Sep 25 '14 at 23:24
  • @daveshaw I would recommend creating a separate answer about the security-proposed ppa. – nanofarad Sep 25 '14 at 23:25
  • Worked for me on my crufty old 12.04 machine. – qneill Sep 26 '14 at 02:39
  • 2
    Fix for CVE-2014-7169 is available in the update manager (for me). – Calmarius Sep 26 '14 at 09:51
  • I am on Ubutnu 13.10 (and I do not want to update my distribution). My bash version is 4.2-5ubuntu3 It is not in the list of fixed versions given above. What can I do?? – lpdbw Sep 29 '14 at 12:41
  • 1
    @lpdbw I'm not able to give instructions on releases other that the ones listed on the usn as I have no way of finding a good version and verifying that it is indeed actually secure. – nanofarad Sep 29 '14 at 19:10
  • You mention 4.1-2ubuntu3.1 as safe, but 4.1-2ubuntu3.4 has been released fixing CVE-2014-7186 and CVE-2014-7187. See https://launchpad.net/ubuntu/+source/bash/4.1-2ubuntu3.4 – mgd Oct 02 '14 at 12:31
27

Stole this off of cft over at Hacker News. If you have trouble with your repos like me(Odroid-XU), then this should work nicely if you want to patch/build from source.

TMPDIR=/tmp/bash-src
mkdir $TMPDIR
cd $TMPDIR
#download bash
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 1 999); do 
  wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i
  if [[ $? -ne "0" ]]; then
    MAX=$(expr $i - 1)
    break;
  fi
done
tar zxf bash-4.3.tar.gz 
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 1 $MAX);do
  echo apply patch bash43-$i
  patch -p0 < ../bash43-$i
done
#build and install
./configure && make
sudo make install
cd ../..
rm -r $TMPDIR

Then run:

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

And if you get:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Then you're all good!


WARNING: make install will install bash in /usr/local/bin, so /bin/bash is not modified and can be invoked from curl !!

rubo77
  • 32,486
9

Note: The Security Patch for CVE-2014-7169 has been released as a standard security update. There is no need to add additional ppa's to receive this patch. Only the following is needed.

sudo apt-get update

sudo apt-get upgrade

To ensure you have patched bash correctly, run the following command

dpkg -s bash | grep Version

If you are on 14.04 LTS, you should see an output of:

Version: 4.3-7ubuntu1.4

If you are on 12.04 LTS, your output should be:

 Version: 4.2-2ubuntu2.5
branch.lizard
  • 331
  • 1
  • 4
1

If you are on 11.04: use below steps (it worked for me)

cd ~/
mkdir bash
wget https://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
for i in $(seq -f "%03g" 0 25); do wget https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done

if it is not downloaded required patche then install ftp package

apt-get install ftp
for i in $(seq -f "%03g" 0 25); do wget https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done
./configure && make && make install
apt-get install build-essential
./configure && make && make install

To see if the patch was applied:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
MrVaykadji
  • 5,875
  • 2
  • 32
  • 55
ldrrp
  • 139
0

I'm using Natty 11.04, which is EOL (and I have updated /etc/apt/sources.list to use old-releases.ubuntu.com), so I have to build from source. I wanted to build a .deb, so at least the package manage is "aware" the bash version is not the default one. I am not 100% succesful - however, the package is registered as "newer" and the bash binary ends up fixed, so here is what I did:

apt-get source bash
wget https://gist.githubusercontent.com/drj11/e85ca2d7503f28ebfde8/raw/31bd53ed2e47b220d3c728f5440758e0f76769de/gistfile1.c -O bash_CVE-2014-6271.patch
wget https://gist.githubusercontent.com/drj11/239e04c686f0886253fa/raw/046e697da6d4491c3b733b0207811c55ceb9d927/gistfile1.c -O bash_CVE-2014-6271_plus.patch
cd bash-4.2/

Now, in the (sub)directory bash-4.2/, there is: a file bash-4.2.tar.xz, which needs to be unpacked to get to the bash source; and a subdirectory called debian.

I made the following changes to avoid dependencies on texlive: in bash-4.2/debian/control:

Source: bash
...
Build-Depends: autoconf, autotools-dev, patch, bison, libncurses5-dev,
# texinfo, debhelper (>= 5), texi2html, locales, gettext, sharutils, time, xz-ut
ils
 debhelper (>= 5), locales, gettext, sharutils, time, xz-utils
# Build-Depends-Indep: texlive-latex-base, ghostscript
Build-Depends-Indep: ghostscript

... and in bash-4.2/debian/rules:

binary-doc: bash-install #bash-doc-build
        dh_testdir
        dh_testroot
        mkdir -p $(d_doc)/usr/share/doc/$(p)
        dh_installdocs -p$(p_doc) 
ifeq ($(with_gfdl),yes)
        #cp -p build-bash/doc/bashref.pdf $(d_doc)/usr/share/doc/$(p)/.
        #dh_link -p$(p_doc) \
        #    /usr/share/doc/$(p)/bashref.pdf /usr/share/doc/$(p_doc)/bashref.pdf
else
        rm -f $(d_doc)/usr/share/doc-base/bashref
endif
        rm -f $(d_doc)/usr/share/info/dir*
        #cp -p build-bash/doc/bash.html build-bash/doc/bash.pdf \
        #    $(d_doc)/usr/share/doc/$(p)/
        #dh_link -p$(p_doc) \
        #    /usr/share/doc/$(p)/bash.html /usr/share/doc/$(p_doc)/bash.html \
        #    /usr/share/doc/$(p)/bash.pdf /usr/share/doc/$(p_doc)/bash.pdf
        dh_installchangelogs -p$(p_doc) bash/CWRU/changelog
        ...

To change the version, in this bash-4.2/ directory, do:

bash-4.2$ dch --local patchCVE

... and fill in the notes in the changelog when asked. This will ensure that the .deb (and related metadata) is called (in my case) bash_4.2-0ubuntu3patchCVE1_i386.deb.

Then you can try building with dpkg-buildpackage -us -uc or debuild command. Note - either of these will re-unpack the source from the zip - thus overriding any patches you may have had! Still, run one of these once so the source is unpacked and built (note debuild may still fail in the end due to texlive, but it should unpack and build the source).

Then, apply the patches; note you should use -p1 here, because currently you're in the bash-4.2/ directory:

bash-4.2$ patch -p1 < ../bash_CVE-2014-6271.patch 
bash-4.2$ patch -p1 < ../bash_CVE-2014-6271_plus.patch 

Then rebuild patched version by running:

bash-4.2$ fakeroot debian/rules build 

This would rebuild the executable; to test it:

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

To build the .deb files, run:

bash-4.2$ fakeroot debian/rules binary

This will save the .deb files in the parent directory; to list their contents:

bash-4.2$ dpkg -c ../bash_4.2-0ubuntu3patchCVE1_i386.deb

To install the .deb:

bash-4.2$ sudo dpkg -i ../bash_4.2-0ubuntu3patchCVE1_i386.deb

However, for some reason, this .deb contains an unpatched binary (?!), so I had to additionally do:

bash-4.2$ sudo cp bash-4.2/build-bash/bash /bin/

... and after that, the test started passing correctly for me:

$ env VAR='() { :;}; echo Bash is!' bash -c "echo Bash Test"
bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR'
Bash Test
sdaau
  • 3,056
  • Question: The Original Question states 1 possible attack vector as "scripts executed by unspecified DHCP clients". What does this mean? Does this mean that Ubuntu's /sbin/dhclient <-- is vulnerable? – Bran Oct 10 '14 at 01:29
  • I think maybe the unspecified clients means, that the Ubuntu has a infected /sbin/dhclient, which then runs commands which lead to the bash script launching shellshock. Is that what DHCP Clients are vulnerable to shellshock? (Hope that makes sense, see my above message from Oct. 10) – Bran Oct 23 '14 at 04:06