22

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?

bwDraco
  • 45,747
  • 43
  • 165
  • 205
Claus
  • 223
  • 1
  • 2
  • 5
  • 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 http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it/ –  Sep 26 '14 at 04: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

4 Answers4

29

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.

Community
  • 1
unkilbeeg
  • 456
  • 4
  • 9
  • 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! – joelparkerhenderson Sep 27 '14 at 00: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. – Jas Panesar Sep 29 '14 at 17:35
  • @rubo77 It needs to now be 1 27 (the new 27 patch is the most important) – joelparkerhenderson Sep 29 '14 at 17:54
  • I had to install some dependencies before successfully compiling bash: `sudo apt-get install build-essential bison texinfo` – jcarballo Sep 30 '14 at 14:46
  • does it fix CVE-2014-7169 and CVE-2014-7186? I'm still vulnerable to them after running these commands. I'm using the checks of https://www.linode.com/docs/security/security-patches/patching-bash-for-the-shellshock-vulnerability – Florent2 Sep 30 '14 at 15:19
  • It doesn't look like there is a patch out for 7186 or 7187. 7169 *is* covered by the patches here. Using the checks from the Linode site, my machines show as *not* vulnerable to 7169. – unkilbeeg Sep 30 '14 at 15:53
  • 1
    Added patch 28. This *does* appear to fix the CVE-2014-7186/7187 vulnerability. – unkilbeeg Oct 01 '14 at 15:13
  • @jcarballo: It works, if I have just installed `sudo apt-get install build-essential`. Why bison and texinfo? – rubo77 Oct 06 '14 at 15:05
  • @rubo77: I suppose that in different systems (distributions, server/desktop version, etc.) when you run "./configure" the build can be setup differently. In my case, bash was asking me to resolve the bison and texinfo dependencies (the build failed). I could've possibly got around that by setting up flags for ./configure (see `./configure --help`), but I didn't need that. – jcarballo Oct 06 '14 at 17:44
  • This is a duplicate of [What is the CVE-2014-6271 bash vulnerability (Shellshock) and how do I fix it?](http://askubuntu.com/a/528171) where the script is adapted to **download all patches** – rubo77 Oct 06 '14 at 19:47
2

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.

Erik Duindam
  • 31
  • 3
-1

The command should be

sudo apt-get update && sudo apt-get install --only-upgrade bash
Mokubai
  • 89,133
  • 25
  • 207
  • 233
ColdenZero
  • 9
-3

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.

R.. GitHub STOP HELPING ICE
  • 1,901
  • 1
  • 16
  • 25
  • 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 07: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". – R.. GitHub STOP HELPING ICE 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. – DocSalvager Oct 02 '14 at 02:05