We’ve moved! You can now read the latest and greatest on Mac adware and malware at Malwarebytes.

What does the “Shellshock” bug affect?

Published September 25th, 2014 at 9:48 AM EDT , modified September 25th, 2014 at 10:26 AM EDT

The Internet’s tech news sites are awash in reports about the newly-discovered bug in the bash shell, now being called “Shellshock.” However, much of the coverage is either confusing for non-techies, or is misleading or even outright wrong. So what is this “Shellshock” thing, and what does it mean to you?

TerminalFirst, let’s look at exactly what this is. All Unix systems have one or more “shells,” which are basically environments that accept input in the form of text-based commands from the user and execute those commands. The Terminal app in Mac OS X is essentially such an environment, wrapping the Unix shell in an app. In the Terminal, when you type a command like “ls -al”, that command is interpreted and executed by the shell, which then also displays the output of the command.

There are a number of different shell programs: the Bourne shell (sh), Bourne-Again shell (bash), C shell (csh), Debian Almquist shell (dash) and many others. Recent versions of Mac OS X use the bash shell by default in the Terminal, and it is the bash shell specifically that suffers from the Shellshock bug.

The bash shell has what are called “environment variables.” These are essentially the preference settings for bash, and they can be changed, either by editing a configuration file or by executing a command in the shell. The Shellshock bug starts with setting a bash environment variable. It would seem, at first glance, that setting an environment variable isn’t a security issue, since doing so requires that the attacker already have access to the system. However, there are cases where scripts running on web servers may put input from the user’s browser into an environment variable, and then run a bash script.

The issue is that one can choose an environment variable setting that will include code that is run just before the next bash script executes. In other words, a hacker could send a malicious bit of data to a vulnerable server, containing arbitrary bash code, and that server will execute the code.

As an example, a Mac user can run the following command in the Terminal:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

On a vulnerable system, this will result in the following output:

this is a test

Essentially, this code does two things: it sets an environment variable, named x (the name doesn’t matter), to a value that includes the “echo vulnerable” command, and then it executes the command “echo this is a test” in a new bash shell. On vulnerable systems, the code in that environment variable will be executed before the command sent to the new bash shell.

This is a huge problem for vulnerable servers, because a shell script can do anything. An attacker using this bug could download and install malicious software on the server, grab files and transmit them somewhere, open existing (but disabled) services to gain remote access to the server, erase large quantities of data, etc.

However, as serious as this bug is, it’s important to cut through some of the FUD (Fear, Uncertainty and Doubt) being spread about it. First, this is not a “virus” or any other kind of malware. I’ve already seen people referring to this as a virus that is “infecting Macintosh computers,” which is absolutely not the case.

Further, it’s important to understand that the applicability of this bug is fairly limited. Obviously, if I could run the example command above on your system, you’d have bigger problems than that, since I could just run a malicious command directly. The problem only comes when a remote attacker can somehow set an environment variable, and that’s just not a likely possibility on any end-user computer. It’s a problem for certain web servers, for example, but the average Mac will not have any internet-accessible server processes that allow for setting of bash shell environment variables.

If you are running a Mac web server, this could be a problem for you. You’ll need to closely examine your setup to make sure that it’s not running any CGI scripts or the like that will take untrusted input from someone connecting to the server and put it into an environment variable.

ipaddressIf you have a Mac running any kind of server processes – and keep in mind that things like printer or scanner software often include some kind of server process – that is directly accessible over the internet, you will need to to take measures. If your Mac’s IP address, as reported by the Network pane of System Preferences, doesn’t start with 192.168 or 10.0, it is probably connected directly to the internet, and anyone on the internet can make connection attempts to your computer. In such a case, it would probably be wise to put a router of some kind, such as a wireless router, between your computer and the internet device it is connected to.

You should also review your wireless router’s settings to make sure you haven’t enabled port forwarding to allow remote connections to your Mac. How this is done will depend on your wireless router. Consult the documentation for that router.

Hopefully, Apple will update bash shortly, fixing the issue on Macs. But until then, this problem is still only likely to affect servers. The vast majority of Mac users will not be affected in any way, except through possible compromises of servers they depend on.


Thursday, September 25, 2014 @ 10:21 am EST: Forgot to mention one important thing that many people probably own that may be vulnerable, and that there may not be any available patches for: wireless routers! These often incorporate basic web servers as a means for configuring the router, and depending on the router, it may be vulnerable to Shellshock. I advise talking to the manufacturer of your wireless router to find out whether it is vulnerable or not. First-tier tech support probably won’t know anything about this yet, but if you get through to a higher-tier tech who says “What’s Shellshock?” that’s probably a sign that you should throw out the router and get one from a different manufacturer! 🙂

Tags: , ,


  • David Acland says:

    You can update the version of bash now if you’d rather not wait:

    As you mentioned, a lot of apps and processes on Mac OS X run “server” processes, such as CUPS so it is a problem for client Macs as well.

    • Thomas says:

      There are some preliminary reports saying that patching bash at this time is not enough, and that there’s still a vulnerability in that version of bash. I don’t know much about that yet, but it would be wise to keep an eye on this.

    • Thomas says:

      That page will also not work, because the latest version of bash is still vulnerable, just in a slightly different way. In fact, this is even pointed out on that page, under “Testing for the new vulnerability.”

  • john says:

    I’ve tested this in the latest version of the developer Yosemite release and found no vulnerability.

  • John Fallon says:

    Realistically, the home user who isn’t hosting a OS X web server exposed to the internet faces little risk. (If they are, this probably isn’t the worst risk.) A corporate network would be a different matter. I’d be more concerned about a wifi router (or an exposed Synology NAS) for myself.

    I’d be tempted to recompile bash myself, but RedHat etc still aren’t sure they’ve identified all the risks. Ah, open source.

    • GByte says:

      An exposed Synology NAS is, as per current knowledge, not affected as it is using BusyBox instead of Bash. Bash of course also runs on a Synology NAS, but needs to installed on purpose and does not belong to the official release.

      Just my two cents, before a big wave of power-downs start with NAS users.

  • Bruce Mattmueller says:

    So is it safe to surf? Is it safe to shop at Amazon?

    • Thomas says:

      That depends on whether Amazon’s servers are vulnerable to the bug, and if they are, whether they have already been compromised. It seems unlikely to me that a big company like Amazon wouldn’t already know if they’re vulnerable and already have a fix in place, or have a LOT of manpower working on a fix… however, if you’re uneasy, it can’t hurt to wait until next week and see what happens.

  • John Fallon says:

    Apparently some of the bigger Synology models do use bash. According to the support site (which lists the models affected), it’s not available to public users. A patch is expected. Not a problem for those of us with 256 megs of ram using BusyBox.

  • Jay says:

    I use my Mac as a router through internet sharing. Would I be just as vulnerable as someone using a normal wireless router?

    • Thomas says:

      If your Mac is directly accessible over the internet (ie, you can access some server processes on that machine from another machine on another network), then it may be vulnerable, depending on what server processes you’re using. However, if there’s another internet device sitting between your Mac and the internet, and managing the packets coming in (rather than just passing them on through), then your Mac should be safe.

  • ~in a small town... says:

    So my AirPort Express sitting across the room from my
    Macs could act as a filter to this kind of issue. What if
    any different setting should be used to be certain it will?

    Most of my gear is older, but since it uses the internet
    it may be adversely affected by bad content, that could
    be avoided by knowing how to do it. Presently the main
    device is a cable IP internet box with coax to AX wi-fi.

    Should it have a firewall in the AX, or does that matter?
    The OS X system has one on, in each Mac; and these
    all see the AX in ‘apple numbered’ addresses.

    Thanks again, Thomas…!

    • Thomas says:

      Any device exposed to the internet could potentially be a problem. The difficulty is saying whether a specific item actually is or not. I have no idea whether an older AirPort Express might have a service that calls bash and is vulnerable to this bug. My suspicion is that it wouldn’t be, but I can’t say that for sure.

  • TJ says:

    Hi there,

    Does anyone know if having XCode and the Command Line Developer Tools on Mac OSX Mavericks creates a vulnerability in a system? My MacBook Pro tested as “vulnerable”, so I patched it using the Apple patch, but now I wonder if the vulnerability was there because of my installation of the aforementioned tools (which I installed a few months ago). Should I uninstall these tools since I don’t use them anymore?

    And if so, what’s the best way to uninstall them?


    • Thomas says:

      No, I don’t believe those tools make you any more vulnerable. As long as you haven’t started up any server processes that invoke bash, you should be fine.

  • TJ says:

    Hi Thomas,

    Thanks for the reply. Geez, I’m confused as to why I was vulnerable then. I basically have no super techy things on my MacBook Pro. I just installed XCode and the Command Line Developer Tools just to check out something in my terminal. That’s all. So weird. I don’t even have a lot of Apps installed on it. I’m not a “developer” or programmer, and nor do I have any server processes (that I know of?).


    • Thomas says:

      Well, keep in mind that all Macs (prior to the patch Apple issued) were running vulnerable versions of bash. If you ran a command in the Terminal and found that you’re vulnerable, that in itself doesn’t mean much.

      Think of it this way… if you have $10,000 in cash in your house, and it’s not in a safe, that’s vulnerable, right? But now suppose the house is locked up tight, with bars on the windows and an active alarm system. That makes the lack of a safe somewhat less important.

      The Mac is like that. You may have a vulnerable version of bash installed, but unless you have unlocked a door (ie, opened some server processes that use bash), there’s no way for hackers to get at it.

  • TJ says:

    Thanks for that analogy 🙂

    May I ask if there is a blanket way to identify server processes? In other words, how do I uncover ones that I’m not aware of? And thanks for your time by the way.

    • Thomas says:

      That’s a good question… there’s really no easy way to do that, but if you haven’t done something to open them, or installed software to do it, you probably don’t have any. Plus, keep in mind that if your Mac is on a wireless network, as most typically are these days, the wireless router should form an effective barricade between your Mac and the internet. So, even if you have a server process running on your Mac, unless you have “poked a hole” through your router (by enabling and configuring port forwarding) to allow traffic through to your Mac, nobody on the internet as a whole can interact with that process.

  • TJ says:

    Thanks for that. I will definitely have a closer look at my router settings.

    You’ve been awesome.

  • JL says:


    Since virtually every home-routers are vulnerable, can they be maliciously configured to enable port forwarding?

    So then they can reach devices connected to that network such as mac/linux desktops or even android phones.

    • Thomas says:

      I would disagree that “virtually every home-router [is] vulnerable” – many are, but many are not. Certainly, if someone gets remote access to your router they could configure port forwarding… though they’d have to know the internal address of your computer, and that will vary if you haven’t already set your computer to have a static IP on the internal network (which is something you would have to do on the computer, not the router).

      So, I think you’re over-thinking this. If you’ve got a wireless router between you and the internet, and you haven’t specifically taken the steps to enable port forwarding to allow remote connections to your computer, you’re not going to need to worry about the Shellshock bug affecting devices on that network.

  • Gerry says:

    Hi Thomas thanks for all the work and information.

    Software Update on my iMac still does not make the update avalable to me and it is now Oct 2 at 11am Sydney time. Should I be applying the patch manually?

  • John Fallon says:

    A further note on this. The Register says (commenting on Vmware’s bash issues) at that Apple’s bash patch may not address all the vulnerabilities discovered so far. The bash test script on Github (which they link to) does seem to indicate a couple of remaining problems. Apple did indicate this was version 1 of the patch. Still probably little concern if you aren’t running an internet-exposed server, I think ( or hope). The script caused bash to crash. I sent the bug report to Apple, who probably had the info already. We can probably expect another patch or two for bash, I suppose.

  • John Fallon says:

    Old news, I guess. Derek at indicates four unpatched issues so far. I turned on the Apple firewall, even though the NAT feature of the Airport Extreme router ought to be enough protection.

  • Colleen Thompson says:

    I’m concerned about running a Snow Leopard Xserve that is providing VPN access to a LAN. Apple isn’t releasing any patches for systems older than Lion. Someone at TenFourFox posted a bash patch package for older systems. Is that the best thing to do right now?

  • GreyGhost says:

    I think that anyone willing, or knowing how, to exploit this vulnerability is likely to go after the servers because that’s where the “Holy Grail” for hackers would be. But patch anyway it’s just prudent.

  • SebastianC says:

    What about if just returning

    this is a test

    Is this then vulnerable or not?

  • SebastianC says:

    Because I get


    when I start to type something into Terminal

  • SebastianC says:

    I dont get the vulnerable message but after RIght Clicking anything and Contextual Options look like it is flickering. It is not stable at all

This post is more than 90 days old and has been locked. No further comments are allowed.