I.e. can I find a close enough package in the next nearest distro? Or is it complicated, and compiling from source is better? Or can I grab it from debian?

(This question is about at least Ubuntu 11.10 and 12.10; I'm betting others are hitting this, so if the advice is different depending on exactly which end-of-lifed Ubuntu, it might help to say how!)

P.S. "Upgrade" will not be accepted as an answer ;-) I know that, but sometimes retiring/upgrading/replacing a server takes time, and I'd like to get bash patched first.

  • 11
    Actually upgrade is the right general answer. If you have a machine that you can't upgrade at will, you should be using Ubuntu LTS or another enterprise distribution - that's what they are for. Planning ahead is the key here. – peterph Sep 26 '14 at 8:44

Short answer for quantal (Ubuntu 12.10): Download and install the bash package from the precise repository.


For quantal (Ubuntu 12.10), I searched for bash packages from nearby releases. I downloaded packages for raring and precise.

Before getting started, I made a backup of my existing bash package, so I could hopefully recover my system if the fresh install failed. (Requires the dpkg-repack package.)

$ dpkg-repack bash

Although probably I should have just copied the executable /bin/bash to /root/bash.vulnerable, since that would be easier to restore in an emergency.


First I tried the package from raring:

$ dpkg -i bash_4.2-5ubuntu3_i386.deb

But that tested as still vulnerable!


So then I tried the package from precise:

$ dpkg -i bash_4.2-2ubuntu2.6_i386.deb

That tested as safe, using the bashcheck script.

Testing /bin/bash ...
GNU bash, version 4.2.25(1)-release (i686-pc-linux-gnu)

Variable function parser pre/suffixed [%%, upstream], bugs not exploitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Not vulnerable to CVE-2014-6277 (lcamtuf bug #1)
Not vulnerable to CVE-2014-6278 (lcamtuf bug #2)

But I really wish I had installed an LTS release. I still plan to do an upgrade when I have time...


Since you do want to keep using an officially unsupported release, your only option is to support it yourself.

I would advise getting the sources for the specific version on Ubuntu (be it 11.0, 12.0 or 13.10) and then applying the same patches that were applied on official packages; for reference, see:

Please note that although the Bash vulnerability is the one that got best media coverage, there are plenty of other vulnerabilities - almost daily - and you should seriously consider subscribing at least ubuntu-security-announce so that you are consistently aware of them. This is specifically more important in your case, since you are using an unsupported release.


Building bash from source is quite straightforward, you need a viable C development environment (gcc, binutils etc.) and the termcap library and headers (default, but you can use curses instead).

You should at least have a backup of your current bash binary before completing this, and ideally a complete backup or rescue disk. Depending on your OS, bash may be a critical part of your boot scripts! New versions sometimes contain non-backward-compatible changes in behaviour.

The same sequence of steps should work for all versions of bash-2.05b to bash-4.3, just replace "4.3" as appropriate, so you can stick with the same version if needed. Unless you're running the rather antique bash-2.05b, which is vulnerable but no official patch is available, AFAICT The fix has also been back-ported to 2.05b.

You should double check on the official site the current patch level, just in case you hit a stale mirror.

mkdir -p /usr/local/src/dist && cd /usr/local/src/dist
wget http://ftpmirror.gnu.org/bash/bash-4.3.tar.gz.sig
wget http://ftpmirror.gnu.org/bash/bash-4.3.tar.gz
wget http://tiswww.case.edu/php/chet/gpgkey.asc
gpg --import gpgkey.asc
gpg --verify bash-4.3.tar.gz.sig
cd ..
tar xzvf dist/bash-4.3.tar.gz
cd bash-4.3
mkdir patches && cd patches 
wget -r --no-parent --accept "bash43-*" -nH -nd  \
  ftp.heanet.ie/mirrors/gnu/bash/bash-4.3-patches/     # Use a local mirror
echo *sig | xargs -n 1 gpg --verify --quiet            # see note 2

cd ..
echo patches/bash43-0?? | xargs -n 1 patch -p0 -i      # see note 3 below

./configure --prefix=/usr  --bindir=/bin \             
        --docdir=/usr/share/doc/bash-4.3 \
        --without-bash-malloc            \

 make test && make install   # see note 6


  1. Use a local mirror for patches, ftpmirror.gnu.org returns a redirect to one, but this doesn't work with the -r option to download the entire directory
  2. (for the tinfoil hats) gpg doesn't set an useful error code, and doesn't complain very loudly if verification fails, look for the string "BAD" in the (copious) output
  3. There are currently 25 27 30 patches for bash-4.3, 25—30 address CVE-2014-6271 and subsequent related issues. There may still be more patches to address this issue! You may receive patch warnings like "Ignoring potentially dangerous file name ../bash-4.3/patchlevel.h", these should be harmless, check that patchlevel.h contains the line #define PATCHLEVEL ... with the expected patch level.
  4. the configure options change the default of /usr/local/, this means make install should overwrite your current bash
  5. --without-bash-malloc selects the libc malloc, rather than a faster (slightly more wasteful) internal implementation. This might affect you if you use loadable bash modules as it can cause an incompatibility, but not many people use this feature. The package for this is probably called bash-builtins.
  6. make test will take some time. You must be root to complete make install (it's often considered bad practise to compile software as root)
  7. Ubuntu, being Debian derived probably use the same extra patches that Debian do, see here for example. These patches may contain features that you use. If you apply the patch to the bash source tree, see the debian/README file for more details.
  8. One more bear-trap, you may also have a static-bash binary, which you should also rebuild. To do this restart from the "./configure ..." step, adding --enable-static-link.

See also, the bash build in Linux From Scratch. The OSS-SEC list is a good place to watch for patches and the current status.

  • He should not build his own bash, but start from the version provided with his distro release (by downloading the source package of that) and applying patches on top of it. What you suggest here has nothing to do with Ubuntu and it's not the advised way to support autonomously a package for Ubuntu: if you try to run a version that was not even picked for that specific distro release, you can incur in much bigger work than some missing patches. – Deim0s Sep 29 '14 at 21:12

You may want to assess whether it is critical to fix this bug on your server. Ubuntu doesn't use bash as /bin/sh, so only attack vectors where bash is called explicitly are a concern. Check for:

  • CGI scripts executed by bash (starting with #!/bin/bash rather than #!/bin/sh)
  • DCHP client scripts executed by bash
  • Restricted accounts with bash as their shell or that execute bash scripts
  • More generally, any situation where a bash (not sh) script gets executed with an environment variable whose content may be provided by an adversary (note that scripts executed via sudo aren't vulnerable thanks to sudo's own filtering)

The following command locates bash scripts in the current directory and its subdirectories:

find . -type f -executable -exec file {} + | grep 'Bourne-Again shell script'

If any of these scripts is executed from an attack vector, you need to upgrade bash, or change these scripts to run under dash or ksh. Check also for restricted accounts whose login shell is bash, and for scripts that call bash explicitly (bash -c '…', bash /path/to/script, …).

If you can't find a binary to upgrade bash on your system, you can download the source, apply the patch for your version and recompile (install the build-essential package as well as bash's build dependencies — autoconf autotools-dev quilt bison libncurses5-dev texinfo debhelper texi2html locales gettext sharutils time xz-utils dpkg-dev as of Ubuntu 12.04).

Even if you don't find any vulnerable script, upgrading is a good idea. You should never run a system for which security upgrades are not readily available. This vulnerability is in bash, which may or may not affect you, but the next vulnerability could be in a critical component of your system.

  • I have seen many times DHCP mentioned as a potential attack vector, but would you mind elaborating? On Ubuntu scripts use /bin/sh, that is dash – Deim0s Sep 29 '14 at 21:13
  • @Deim0s Like the potential other attack vectors, DHCP is a lot less likely to be an actual attack vector when /bin/sh is some shell other than bash. Only a system where some script uses #!/bin/bash is at risk. – Gilles Sep 29 '14 at 21:22
  • but the OP is asking about Ubuntu, hence my precisation – Deim0s Sep 30 '14 at 14:05

Someone made a perl script that does just that.

Github repository for batchscript.

$ git clone https://github.com/sillymoose/bashfix.git
$ cd bashfix
$ chmod +x bashfix.pl
$ ./bashfix.pl
Bash version 4.2.13 detected
Created working directory /tmp/PIRKRioxmM
Downloading Bash
Downloading Patches
Bash patched to level 52
Bash fully patched!
Configuring Bash ...
Building and testing Bash ...
Success. New Bash binary built!
Making backup copy of /usr/bin/bash at /usr/bin/bash.bak
Making backup copy of /bin/bash at /bin/bash.bak
Bash version 4.2.52 is now installed

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.