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?
-
5What 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.– RamhoundCommented Sep 25, 2014 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.– ClausCommented Sep 25, 2014 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/…– user372442Commented Sep 26, 2014 at 4:33
-
1leave 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.– 300D7309EF17Commented Sep 30, 2014 at 22:58
Add a comment
|
4 Answers
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! Commented Sep 27, 2014 at 0:14
-
Whilst the
./configure --prefix=/ && makeruns fine, themake installseems to requiresudo– StewartCommented Sep 27, 2014 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. Commented Sep 29, 2014 at 17:35
-
@rubo77 It needs to now be 1 27 (the new 27 patch is the most important) Commented Sep 29, 2014 at 17:54
-
1Added patch 28. This does appear to fix the CVE-2014-7186/7187 vulnerability. Commented Oct 1, 2014 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
-
2This won't help; as the OP said, it isn't supported any more, so there won't be an upgrade for bash. Commented Sep 29, 2014 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.
answered Sep 26, 2014 at 6:23
R.. GitHub STOP HELPING ICER.. GitHub STOP HELPING ICE
2,0292 gold badges17 silver badges25 bronze badges
-
5That's a bit like saying, "we found that you can have segfaults in C++, just use Java instead"...– DevSolarCommented Sep 26, 2014 at 7:04
-
3A 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". Commented Sep 26, 2014 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. Commented Sep 30, 2014 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. Commented Oct 2, 2014 at 2:05