Red Hat recently announced a major security-related bug in the Bash shell. Some are calling it the "shellshock" bug. Since OS X is built off of Unix, is it vulnerable to attacks that exploit this bug?

As an end user, do I need to worry about an immediate fix? Or is it better for me to wait for an official software update from Apple?


5 Answers 5


Yes you are technically vulnerable. So if you feel like panicking or billing a panicked client for a few hours of panic work, go for it!

But the reality is unless you allow SSH access from remote connections or a web server that runs server side scripting, you are not at risk. You are only truly vulnerable if someone you do not know can remotely access your machine & do so in a way where a Bash command can be executed.

Meaning your desktop Mac—which really does not run server applications of any kind—is not at any serious risk. I am willing to eat some proverbial “humble pie” here, but I do not think the majority of Mac users out there will be at risk at the end of the day.

So this issue is mainly of concern to system administrators on Mac OS X & Unix/Linux servers exposed to the world, not desktop users who do not enable SSH sharing.

Perhaps there is an edge risk of a Mac malware or virus being created to exploit this risk, but I doubt it.

EDIT: And just to elaborate how this issue is—in my humble opinion—not really an issue to most average users, yes I can run the following command from bash on Mac OS X 10.9.5:

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

And I see this:


Guess what? That is only terrifying if you don’t rationally think this out. I had to already have been logged into my Mac to even open the Terminal. And to negate what I said about SSH above, to even get to the point I can run this test even if SSH is enabled I would still have to be logged in to begin with. And then—let’s say I get access via SSH—the command does not allow me to do ANYTHING past my normal user rights such as this:

env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'

Meaning if you truly are vulnerable to being exploited by this hack, your core security on the system would have to be so compromised that the fact that bash has a flaw is really the very least of your issues.

This is a concern from an overall control & rights issue as it as the potential to allow unintended access since the behavior extends outside of expected norms. But in my humble opinion, it is not a risk on par with OpenSSL or the garden variety “let me leave my password on a note taped to my screen” risks.

At the end of the day I am still patching all of my Linux/Unix servers I run as standard procedure. And will happily patch the Macs I manage once a fix is out. But for practical day-to-day use I feel fine not worrying about this since I do not understand how a flaw that does not allow for elevated user privileges adds up to anything.

UPDATE: Official word from Apple posted here; emphasis mine:

“The vast majority of OS X users are not at risk to recently reported bash vulnerabilities," an Apple spokesperson told iMore. "Bash, a UNIX command shell and language included in OS X, has a weakness that could allow unauthorized users to remotely gain control of vulnerable systems. With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services. We are working to quickly provide a software update for our advanced UNIX users.”

Translation: What I said above about this being a server issue & not a client issue? Exactly.

A FINAL UDPATE: For anyone struggling with compiling from source, as of September 29th, Apple has officially released patches for Mac OS X 10.9.5, 10.8.5 as well as 10.7.5:

YET ANOTHER FINAL UPDATE: And now, Apple has just released a combination security update today that includes the bash update as well!

Note: Security Update 2014-005 includes the security content of OS X bash Update 1.0

  • 7
    "or a web server that runs server side scripting" -- or have an application running, listening on an open port that allows RPC calls to be made that end up running shell commands. This could be any number of things as there are plenty of standard applications that do their RPC. I think this answer is very naïve. It's very easy to be "running a web server" inadvertently in the course of running an application that does some client-server type thing.
    – Ian C.
    Commented Sep 25, 2014 at 6:09
  • 8
    The guest account is not available to ssh. In fact, it is not even possible to make it available to ssh, IIRC. The fact is, for the vast majority of OS X users, the bash vulnerability is not an issue at all. For those of us where it is an issue, we need to recompile bash as soon as a tested fix is available, but that's not now.
    – lbutlr
    Commented Sep 25, 2014 at 13:54
  • 3
    +1 for being a voice of sanity! Yes, technically this is a problem, but good luck exploiting it, unless you are running a service that allows running arbitrary commands, and then guess what? You already have a problem! I know that this is a little more severe, since setting a variable should never execute code, but most programs pass arguments as arguments, not environment variables. Commented Sep 25, 2014 at 19:16
  • 3
    "That is only terrifying if you don’t rationally think this out." can not be understated. This same rule applies to any security fad, computer security, homeland security, personal security. Humans are notoriously easy to put into panic mode, and very hard to get them out.
    – corsiKa
    Commented Sep 26, 2014 at 12:50
  • 2
    @JeffBurdges: regarding "Installation scripts usually use bash, creating privilege escalation risks", why would a malicious installation script need to use this exploit? If the user is installing a malicious installation script (a trojan horse) then the code wouldn't need to invoke this bug, it gets root anyway.
    – Josh
    Commented Sep 27, 2014 at 3:50


Type this in your shell

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

If it says vulnerable then you are vulnerable.

If it says

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'

then you are good.

Edit: link to the fix

  • 4
    Thanks. I updated the question - if we find that we're vulnerable, how can a Mac user fix it?
    – hairboat
    Commented Sep 25, 2014 at 1:34
  • 1
    → abby: please see this related answer: apple.stackexchange.com/a/146851/22003 .
    – dan
    Commented Sep 25, 2014 at 7:28
  • 2
    Try this env X="() { :;} ; echo busted" /bin/sh -c "echo completed" -- Even after patching my system, this one coughs up a 'busted' on the command line. Bah. Commented Sep 25, 2014 at 14:15
  • Looks like zsh is also vulnerable.
    – Ɱark Ƭ
    Commented Sep 25, 2014 at 14:38
  • 1
    @Mark nope, zsh is safe. you need to replace "bash -c" with "zsh -c" to test it.
    – ismail
    Commented Sep 25, 2014 at 18:08

As an end user, check that:

  • your guest account is off:

    System Preferences > Users & Groups > Guest User
  • your ssh access is off:

    System Preferences > Sharing > Remote Login

By default these are both off on Mavericks.

As an end user, it is safer to wait for an official Apple security update fixing this bash vulnerability.

  • 1
    These are irrelevant. Either of these, by their very nature, grant users access to run commands on the system, so if you have them enabled then it is your intention to allow users to run commands. The Shellshock bug is a means for users whom you didn't intend to be able to run commands to be able to do so, E.G. a user of the web server you run. So, your answer should say "Disable Web Sharing" (but that's just one thing to check)
    – Josh
    Commented Sep 27, 2014 at 3:52
  • I am annoyed Apple did not advise to turn off those settings. Who would enable them? I would. I am a Mac user since 1986, a full-time web application developer (so ssh is my life), and a dad (so a Guest account for the kids is not such a bad idea). I know plenty of people who are like me in these ways who use Apple laptops. Want to lose us? Leaving this vulnerability open is a good way.
    – minopret
    Commented Sep 27, 2014 at 23:42

All Mac OS X machines are technically vulnerable to “Shellshock,” until Apple issues a security update that patches bash, but..

Your question should be: Can I be hacked remotely?

There is so much software that uses bash absent-mindedly that answering that question is extremely hard. If you're worried then I'd suggest several changes in System Preferences to prevent remote exploits:

  • Disable ALL sharing services under Sharing Preferences.
  • Enable the Firewall under Security and Privacy.

If you're particularly worried then press the Firewall options button to :

  • Uncheck Automatically allow signed software to receive incoming connections.
  • Check Block all incoming connections.

There is still a respectable chance that you're vulnerable to a level attack using DHCP, Bonjour, etc., but hey if you need another service then obviously you could leave it running while you hope it doesn't get exploited. And you'll need to leave the firewall more open too. It'll likely be fine if you're machine lives behind another firewall.

Also, are there local privilege escalation attacks enabled by “Shellshock?” Yes, almost surely. I wouldn't worry though because Mac OS X has enough similar attacks. Apple doesn't patch local privilege escalation bugs quickly. And Apple creates them frequently with Apple Script enabled services. Just assume all Mac OS X machines are always vulnerable to local attacks. If you need to attend hacker conferences like DEFCON then buy yourself a Linux box for that purpose.

Update: There are instructions for recompiling your own fixed bash and another questions covered doing so too. I'll do this myself, but IMHO that's overkill if you do not run any servers and keep Apple's firewall turned on anyways.

Update: If you're comfortable with terminal usage, there is a program called execsnoop mentioned here that'll let you test whether bash is usually called by your server processes. Ain't a magic bullet since the server process might call bash only in unusual situations, but it'll give you a good idea.

Finally, Apple isn't very good about patching security vulnerabilities, but they're good at PR, so this'll get patched relatively fast. It's therefore reasonable to think "I don't need to run faster than the bear, I only need to run faster than the vast number of easily exploitable servers on the internet". :)

  • 2
    There is no chance Macs are vulnerable to an attack using DHCP, since it doesn't use Bash.
    – user79406
    Commented Sep 26, 2014 at 19:41
  • 1
    How do you know that? Initial advisory was a vulnerable DHCP client. And many articles speculate that Mac OS X and/or iOS DHCP clients might be vulnerable. All servers should be assumed to be vulnerable unless proven otherwise. Commented Sep 26, 2014 at 21:44
  • 1
    No, they should not be; that is absolute FUD. You can examine both the open source code for OS X's dhcp implementation and measure system calls yourself to verify.
    – user79406
    Commented Sep 27, 2014 at 0:43
  • 3
    @JeffBurdges, OS X hasn't used shell exec with DHCP since 10.3, and before that bash wasn't installed on the system. DHCP on OS X is just not an issue with Shellshock. (One less thing about which to worry. :)) Commented Sep 27, 2014 at 5:38
  • 1
    → Jeff: please consider: strings /usr/libexec/bootpd | egrep '/bin|bash' and nm -a /usr/libexec/bootpd | egrep 'fork|exec'. By reading these commands output on different versions of MacOS X, you might reconsider your risk analysis due to dhcpd on MacOS X… but this one alone :(.
    – dan
    Commented Sep 27, 2014 at 12:25

I made this tool as soon as I heard about this vulnerability. It'll provide you with a link to a article to patch your shell if the tool determines you're vulnerable.

Requires Mac OS X 10.6 and up.

  • 3
    Maybe it's just me ... but the idea of running some random person's code to test for an exploit just seems like a really bad idea when you can just as easily paste a string (that's clearly only running the test & nothing more) into a terminal window.
    – Joe
    Commented Sep 27, 2014 at 19:35
  • I agree, that's why the source is on code.google.com/p/shellshock-check Commented Sep 28, 2014 at 9:44
  • Sometimes though, it can offer ease-of-use for testing multiple systems. Commented Sep 28, 2014 at 9:45
  • I don't see the benefit of this thing. Checking the vulnerability is much easier done by pasting a simple command line in the terminal window. Commented Sep 29, 2014 at 14:58
  • When testing multiple machines though, especially in my case, as that is what I do, putting a flash drive in and opening Shellshock Check.app is much easier than opening Safari, looking up the bash command to check, then opening Terminal, pasting that command and then pressing Enter. It is much faster to plug in a flash drive, and open one application. Commented Sep 29, 2014 at 15:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .