NB: Apple has released the following patches:
This was tested on 10.9.5.
A new vulnerability has been discovered in the bash shell which is affectionately being called “shellshock”. It’s worth pointing out that this is quite serious and should be addressed.
There are some comments on blogs stating that “it’s not as bad as we think” so I will take a moment to explain what it could mean to you so you can make up your own mind.
The bash shell is built into almost every Mac OS X system (I say almost, as some clever person may have decided to remove it from their Mac). The deep, technical description taken from the following site is:
“Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to (indirect) child processes. Current bash versions use an environment variable named by the function name, and a function definition starting with “() {” in the variable value to propagate function definitions through the environment. The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function definition.
For example, an environment variable setting of:
VAR=() { ignored; }; /bin/id
will execute /bin/id when the environment is imported into the bash process. (The process is in a slightly undefined state at this point. The PATH variable may not have been set up yet, and bash could crash after executing /bin/id, but the damage has already happened at this point.)
The fact that an environment variable with an arbitrary name can be used as a carrier for a malicious function definition containing trailing commands makes this vulnerability particularly severe; it enables network-based exploitation.”
Source: http://seclists.org/oss-sec/2014/q3/650
In a nutshell, this means that the shell has a small bit of code that it runs without question on certain older versions of bash. This code can be modified very easily so the attacker can add their own “bits” into it to give them access to your Mac and do as they wish.
From what I can gather it seems like this is only really a problem for computers that have some kind of external access enabled such as SSH or a web service. Some people have said “well that’s ok, I’m not running a web server”. The problem is, you probably are.
A lot of applications start up a small web service to perform their functions, not to mention the cups service running on port 631 that is accessible through a web browser by going to http://localhost:631.
I took a look at my Mac to do a quick port scan and see if I could “lock things down” but have decided that will be ultimately unachievable without a lot of work.
After a bit of digging, I decided that upgrading my bash shell was the simplest course of action so here are some instructions.
How to upgrade bash in OS X to version 4.3.25 to avoid the shellshock attack:
Its probably worth checking first that you are affected. Run the following command in the terminal and it will report back to say if you are vulnerable:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
You can also check the actual version you are using:
bash --version
You’ll get an output something like:
dave$ bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
It affects versions 1.13 (22 years ago) up to 4.3. I’m running 3.2.51 which is affected.
To start the upgrade process, install brew from the command-line by entering the following command and pressing return:
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Quick note – I had XCode installed on my Mac but I hadn’t launched it since a recent update and so the above command was complaining that it couldn’t run properly. I just had to launch XCode, accept the Ts & Cs and then re-run the command.
Once complete, install the newest version of bash:
brew install bash
In my case it put it into /usr/local/Cellar/bash/4.3.25/bin/bash. The standard place for bash is /bin/bash.
Finally, you can either edit /etc/shells to remove /bin/bash and add the correct path to your new version or replace (after backing up) the default version of bash.
If you do opt to change the path in /etc/shells, make sure you also change the default shell in your user record.
The default shell can be changed from System Preferences or with dscl, but all three options just modify /var/db/dslocal/nodes/Default/users/user.plist
I just backed up the existing /bin/bash with:
mv /bin/bash ~/Desktop/
and dropped in the new version with:
dave$ bash --version
GNU bash, version 4.3.25(1)-release (x86_64-apple-darwin13.4.0)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
So I am running 4.3.25 which isn’t affected.
As a final check, I run the env check which should fail to run.
Disclaimer:
While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. Amsys will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.