I have a system that I administer remotely (2 timezones away) that runs Ubuntu 9.04, Jaunty. For various reasons, mainly that I'm really leery about trying to do a distribution upgrade from so far away, I can't upgrade it to a more recent version. Obviously it's no longer supported and there aren't any official patches. Are there instructions available as to how I can patch the code and recompile bash myself to remove the shellshock vulnerabilities?

  • 5
    What research have you done on this subject? The simplest solution likely would be to rebuild and patch it yourself. You might have to accept this its simply time to update the server.
    – Ramhound
    Sep 25 '14 at 18:05
  • Yeah, that's my fallback option. The server is on its way out, I'm just trying to keep it limping along until the funds come in for its replacement. Were I on-site, I'd bite the bullet and do the update, but I very rarely have that go without a hitch, and without being able to put hands on it I'd rather not risk that if I don't have to.
    – Claus
    Sep 25 '14 at 18:44
  • Just getting some keywords on the page so people can find this. Also worked for me on Mac, OS X, Mavericks based on the test published at arstechnica.com/security/2014/09/…
    – user372442
    Sep 26 '14 at 4:33
  • 1
    leave it unpatched, "limping along" will quickly change. Be very clear, you are using a distro that came out five years ago. Support ended in October 2010. You have many more vulnerabilities to worry about.
    – tedder42
    Sep 30 '14 at 22:58

Stole this from AskUbuntu, from someone who stole it off of Hacker News. Worked on two old servers for me

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" 1 28); 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" 1 28);do patch -p0 < ../bash43-$i; done
#build and install
./configure --prefix=/ && make && make install
cd .. 
cd ..
rm -r src

Update: I just noticed that if you don't add --prefix=/ to the configure command you'll end up with /usr/local/bin/bash that is up to date and /bin/bash will still be vulnerable.

  • There's a bug in the script: the "0 25" sequence should be "1 26". If you're reading this and able to edit the answer, please update it. Thanks! Sep 27 '14 at 0:14
  • Whilst the ./configure --prefix=/ && make runs fine, the make install seems to require sudo
    – Stewart
    Sep 27 '14 at 11:45
  • Thanks for putting this out there -- a fair way to patch things while migrating. Some folks have many vms and it's not realistic to rebuild each one. Using this as an immediate fix while solving it more long term by being on a more updated installation is key. Sep 29 '14 at 17:35
  • @rubo77 It needs to now be 1 27 (the new 27 patch is the most important) Sep 29 '14 at 17:54
  • 1
    Added patch 28. This does appear to fix the CVE-2014-7186/7187 vulnerability.
    – unkilbeeg
    Oct 1 '14 at 15:13

There's also a solution of updating your sources.list to the newest one and then using apt-get to upgrade only bash. It's really quick and I've written an article about it. Here's what you basically do:

Upgrade to latest Ubuntu 'trusty' apt-get repositories (you might also have to change old-repositories.ubuntu.com URLs if you use them, check linked article):

sudo sed -i 's/YOUR_OS_CODENAME/trusty/g' /etc/apt/sources.list

Upgrade bash / apply fix:

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

And possibly change back apt-get repositories.


The command should be

sudo apt-get update && sudo apt-get install --only-upgrade bash
  • 2
    This won't help; as the OP said, it isn't supported any more, so there won't be an upgrade for bash. Sep 29 '14 at 8:17

One simple option is just not to use bash. Make sure dash is installed and that /bin/sh is a symlink to dash, not bash. (This is the default on some versions of Debian, but I'm not sure about Ubuntu.) If you have user accounts for ssh access with forced commands, you need to change their login shells too. You might also need to check for any scripts explicitly using bash; grepping for #!/bin/bash should find them.

  • 5
    That's a bit like saying, "we found that you can have segfaults in C++, just use Java instead"...
    – DevSolar
    Sep 26 '14 at 7:04
  • 3
    A closer analogy would be telling someone experiencing a bug in GCC to try clang. Both implement the same language (with different but sometimes overlapping sets of nonstandard extensions) and it's unlikely that the actual need is for "bash" but rather for "shell interpreter". Sep 26 '14 at 16:42
  • Like you said, there are scripts that could explicitly use bash. Even if you grep for the existent files that use bash, in the future someone could add a new script to the system that uses bash explicitly. Same goes for embedded systems that use busybox (/bin/sh points to busybox), but also have bash installed. The best thing is to update bash in the vulnerable systems.
    – jcarballo
    Sep 30 '14 at 14:50
  • The majority of Unix/Linux scripts require bash or some other modern shell like ksh or zsh. These have a great many functionalities that people have come to expect in any language but are not present in the "bare-bones" shells like (BusyBox)ash/Dash/sh(original). These simpler shells have only 20-30% of the functionality of the bigger shells which makes them faster. However, they require the extensive use of external utilities for many common operations like advanced string-handling and pattern-matching. Bash and such can run ash, et.al. scripts. But not vice-a-versa. Oct 2 '14 at 2:05

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.