The Bash ‘Shellshock’ bug and workaround

“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,” David Acland reports for Amsys. “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 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,” Acland reports. “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.”

Acland reports, “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 in the full article here.

Related article:
U.S. government warns of Bash flaw affecting Apple’s OS X, other Unix-based systems – September 25, 2014


    1. This time it most definitely is not FUD. This affects virtually every UNIX and Linux out there, and it’s a serious threat. OSX is vulnerable. Follow the howto and patch your bash.

      Now, probably more importantly given that they’re used on public networks more often, does anyone know whether iOS and Android devices are vulnerable to this too?

    1. I wonder if some printers may enable it?
      Mine is disabled, so i’ll just wait for a security update. (Which I assume will be shortly)

      For those that say this is FUD..
      “A lot of applications start up a small web service to perform their functions”

      So while it technically affects all Macs.. few may actually be vulnerable cause it is disabled by default, but some apps may turn it on.. and as we all know.. not everyone runs the same apps.

      Wonder if some of the apps only turn it on when the app is running? and turn it back off when they close..

  1. This is a huge problem for anyone running a web server – these people should patch their servers immediately.

    For a typical Mac, however, this isn’t much of a concern. OS X is technically vulnerable, but it is unlikely you have enabled the type of network access that would make your computer an easy target for outsiders to use this. Apple will release a patch for this in a few days, long before anyone develops a clever way to use this exploit on regular Macs.

    1. I’ve tried the method provided at several times. It consistently runs into this problem:

      curl: (60) SSL certificate problem: unable to get local issuer certificate
      More details here:

      This was after making certain Xcode 6.0.1 was installed, booted and activated. I haven’t dug any further into the problem. I’ve tried a couple other methods as well. NONE of them work adequately. But note that I loathe CLIs. I only use them when forced to specifically because of annoying stuff like this. I find it to be RARE that a tech geek is capable of actually explaining how to do something correctly or adequately. 😛

  2. These work arounds don’t work. The instructions are missing steps. You can download the latest one but they don’t tell you how to remove 3.5.2 and replace it with version 4. Apple will run a software update that will do all of this for you and you won’t have to pull your hair out to do it this way.

    1. You are quite CORRECT b9bot. As I ranted above: I find it to be RARE that a tech geek is capable of actually explaining how to do something correctly or adequately.

      Stop voting b9bot down folks unless YOU can provide an update method that actually WORKS. Then you have my permission. 😉

  3. … got this:
    -e:1: syntax error, unexpected tLABEL, expecting keyword_do or ‘{‘ or ‘(‘
    -e:1: unknown regexp options – raw
    -e:1: syntax error, unexpected ‘)’, expecting end-of-input

    Is it missing a “(“? That would seem likely, as another error sees the “)” at the end.
    That “raw” is a regexp??? Perhaps another error led to this “error”?

  4. I followed the instructions, bash 4.3.25 compiled without problems (which by the way does not replace /bin/bash but is written to /usr/local/Cellar/bash/4.3.25/bin/bash) but when I run the vulnerability test I still get the “vulnerable” message.

    1. Right, because your PATH is not pointing first to the Homebrew version.


      which bash

      and you should see that it’s still looking at /bin/bash

      You really want the entire system seeing the Homebrew version because unless you’re the one writing the exploit, the hackers out there will not be using your profile and therefore your PATH… you could (I haven’t tested this and am typing in an uneditible blog post feedback field) move the vulnerable executable aside using the mv command, then either copy into /bin/ the Homebrew one or create a link to it. There may be real security implications in that which I haven’t considered. Personally, I’m waiting for the inevitable Apple patch.

      1. Thanks for pointing this out.
        If a modify the test to read
        env x='() { :;}; echo vulnerable’ /usr/local/Cellar/bash/4.3.25/bin/bash -c ‘echo hello’
        it prints
        warning: x: ignoring function definition attempt
        which means the new bash is immune to the shellshock bug
        Now I will move /usr/local/Cellar/bash/4.3.25/bin/bash to /bin/bash

Reader Feedback

This site uses Akismet to reduce spam. Learn how your comment data is processed.