58

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?

hairboat
  • 2,903
  • 18
  • 51
  • 72
  • 1
    see also http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271 – nohillside Sep 25 '14 at 04:32
  • To see what actions affect OSX see http://security.stackexchange.com/questions/68123/are-ordinary-os-x-desktops-at-risk-from-bash-shellshock-bug-cve-2014-6271 – mmmmmm Sep 25 '14 at 11:49
  • Updated the question so it's less of a dupe and more of a request for advice for laypeople. – hairboat Sep 25 '14 at 19:21
  • 1
    Apple has released a fix now: http://support.apple.com/kb/DL1769 – A T Sep 30 '14 at 04:58

5 Answers5

46

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:

vulnerable
hello

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

Giacomo1968
  • 5,623
  • 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. Sep 25 '14 at 06:09
  • 1
    Is the guest account accessible from remote by default? – nohillside Sep 25 '14 at 07:33
  • 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 Sep 25 '14 at 13:54
  • 1
    @JakeGould all it takes in a server running that possibly executes commands via the shell. Plex, for example, is one such there -- where it's doing transcoding and serving up video off your Mac in realtime. The transcoding is done by a shell command and it has an open API for interacting with it that's unauthenticated. Growl is another example. Open ports with listeners are all over the place on your Mac. Even non-listening applications can inadvertently shell out when they receive commands. – Ian C. Sep 25 '14 at 14:51
  • 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. – Paul Wagland Sep 25 '14 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 Sep 26 '14 at 12:50
  • → JakeGould: if guest account is on, then a user can use it. Then by using the bash vulnerability he may force any daemon running as root and using a bash to execute any command with the root priviledges. By default on Mavericks, the guest account is off, and ssh access is off too :). – dan Sep 26 '14 at 16:13
  • -1 Very wrong. There are many tools that use bash : Installation scripts usually use bash, creating privilege escalation risks. All servers should be assumed to use bash unless you know otherwise, not just sshd. In particular, apache could create a remote vulnerability using bash. etc. – Jeff Burdges Sep 26 '14 at 18:43
  • There are likely privilege escalation risks from a guest account too. Who cares though? Any Mac OS X machines is extremely vulnerable once users get access, especially local users. It's server daemons that should scare you, not just sshd though, all server daemons. – Jeff Burdges Sep 26 '14 at 18:51
  • Apache modules, CGI scripts, etc. commonly call bash. Very effective hack right here : https://twitter.com/JZdziarski/status/515135854436962304 And even if your Apache configuration does not call bash under normal operation, no telling what an attacker can convince it to do. – Jeff Burdges Sep 26 '14 at 21:48
  • As I said below, ALL servers should be assumed to call bash unless proven otherwise. And Mac OS X is full of privilege escalation exploits once you reach a shell. – Jeff Burdges Sep 26 '14 at 21:49
  • In fact, your answer is totally wrong!!! Ordinary ssh usage isn't vulnerable since you're already opening a shell, only ssh's restricted login command is vulnerable. Almost no Linux users even know about that, so like no Mac users do. – Jeff Burdges Sep 26 '14 at 22:12
  • I already mentioned that recompiling bash is overkill myself. The correct response for ordinary desktop uses is to turn on firewall and turn off sharing services OR to accept that they're trusting the firewall provided by their router. That's what my comment says. You single out a probably usually non-vulnerable server, ssh, and ignores that an awful lot of people doing rudimentary local web server with unknown active scripting. – Jeff Burdges Sep 26 '14 at 22:22
  • heh. SE edit boxes don't like the Mac's spelling corrector, always creates premature comments. Sorry about that. Anyways.. – Jeff Burdges Sep 26 '14 at 22:27
  • 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 Sep 27 '14 at 03:50
  • Clients may be also vulnerable. https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ – Alexia Luna Sep 28 '14 at 16:29
  • This is all about FUD, perception and reality. The risks for 99% of Mac users are non-existent. BUT: that is no excuse for Apple do delay getting a proper fix out. After the icloud-gate brouhaha I would have thought senior management at Apple would be seriously concerned about something that tarnishes Apple's image. As a regular user I would be worried that Apple does not plug that hole, especially since it so easy to observe using a single line of code! – Albert Godfrind Sep 29 '14 at 13:48
  • 1
    There is a public escalation-of-privilege exploit available for VMWare Fusion (which is typically only installed on clients): http://packetstormsecurity.com/files/128425/vmware_bash_function_root.rb.txt – Scott Dudley Sep 29 '14 at 20:17
  • @ScottDudley: That has nothing to do with VMWare. And it has nothing to do with Mac OS. It just shows that if you run Linux in a VM, that installation is sensitive to the bash vulnerability if it has not been patched yet. I run multiple Linux VMs on my laptop (using Virtualbox) and they are all vulnerable, because I have not patched them yet. They run no web server, and they are only accessible from my host. – Albert Godfrind Sep 30 '14 at 15:13
  • @AlbertGodfrind, that is incorrect--please read the page again. That page claims to contain an OS X escalation-of-privilege exploit (I admit that I haven't tested it). It appears to be an exploit against the VMWare Fusion installation on OS X, and it has nothing to do with Linux at all. A quick read of the code suggests that Fusion might not even need to be running in order to exploit it. – Scott Dudley Sep 30 '14 at 15:26
  • @JakeGould it's escalation-of-privilege, so it broadens the attack surface, and now a weakness in any user process can be combined with this to get root. For example, people above were talking about how if httpd were exploited (which need not happen using the bash flaw!), then you'd only be left with userland access running as the apache user. If you have Fusion and bash isn't patched, then once you get user, you can get root too. Take your pick of the vulnerabilities in various userland processes on <=10.9.4. – Scott Dudley Sep 30 '14 at 16:37
  • @JakeGould, you exploit any user process vulnerability (which could be through shellshock, or through any other problem with a userland processs--say, one of the vulnerabilities in the previous link). That's why it's called escalation-of-privilege: http://en.wikipedia.org/wiki/Privilege_escalation – Scott Dudley Sep 30 '14 at 16:46
  • 1
    @JakeGould, yes, I read the answer and I understand the nuances. Here's a simple example. Some spambot emails a malicious PDF file to your @mac.com address. You don't do anything except flip past the message in Mail.app, which shows the PDF in the preview pane, which then triggers the payload (CVE-2014-4377). Your unpatched bash could turn this userland exploit (bad) into a root-level exploit (worse). – Scott Dudley Sep 30 '14 at 17:16
37

Yes!

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'
hello

then you are good.

Edit: link to the fix

Community
  • 1
Chris Aitchison
  • 461
  • 4
    Thanks. I updated the question - if we find that we're vulnerable, how can a Mac user fix it? – hairboat Sep 25 '14 at 01:34
  • 1
    → abby: please see this related answer: http://apple.stackexchange.com/a/146851/22003 . – dan Sep 25 '14 at 07: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. – Trane Francks Sep 25 '14 at 14:15
  • Looks like zsh is also vulnerable. – Ɱark Ƭ Sep 25 '14 at 14:38
  • 1
    @Mark nope, zsh is safe. you need to replace "bash -c" with "zsh -c" to test it. – ismail Sep 25 '14 at 18:08
  • I've patched Mac OS X's bash 3.2 and included instructions here: https://github.com/ido/macosx-bash-92-shellshock-patched/blob/master/README.md – ido Sep 26 '14 at 16:57
  • @TraneFrancks : Apple uses bash in /bin/sh ... you need to replace both /bin/sh and /bin/bash to be protected. /bin/sh is actually more problematic, as it's the shell that scripting languages are likely to use to execute shell commands. – Joe Sep 27 '14 at 19:38
  • @Joe, I'm well aware of what needs patching. I wrote a tutorial on the process here: http://apple.stackexchange.com/a/146943/91441

    The article was also here, but was deleted by moderators as being a duplicate.

    The problem was that building from Apple source with xcodebuild will do both bash and sh in a single step. Building from vanilla GNU source requires separate compiles. As well, bashbug has a different install location on OS X than the GNU output, so that needs to be moved as well.

     – Trane Francks Sep 28 '14 at 03:43
  • @JakeGould Not entirely true. https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ – Alexia Luna Sep 28 '14 at 16:28
3

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.

dan
  • 12,177
  • 8
  • 58
  • 136
  • 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 Sep 27 '14 at 03: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 Sep 27 '14 at 23:42
2

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". :)

Community
  • 1
Jeff Burdges
  • 1,210
  • 2
    There is no chance Macs are vulnerable to an attack using DHCP, since it doesn't use Bash. –  Sep 26 '14 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. – Jeff Burdges Sep 26 '14 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. –  Sep 27 '14 at 00: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. :)) – Trane Francks Sep 27 '14 at 05: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 Sep 27 '14 at 12:25
  • Not quite. One must review the symbols called by the library that otool -L /usr/libexec/bootpd reports that contains an exec call. And the strings command is pointless since environment variables determine the shell called. I'm impressed however that no liked library calls system. – Jeff Burdges Sep 28 '14 at 03:02
  • @JeffBurdges so wouldn't adding "|SHELL" to the egrep search string (for the strings output) catch that? – jhfrontz Sep 28 '14 at 15:38
  • Also, on that otool -L -- the only output I receive from that is a list of libraries (CoreFoundation, SystemConfiguration, OpenDirectory, libresolv.9.dylib, and libSystem.B.dylib) – jhfrontz Sep 28 '14 at 15:54
  • Yes strings .. | grep SHELL is far more useful than bash, but not absolute. Imho nm -a ... | grep system is the most important, and exec helps too, but that's only for vanilla BSD, Linux, etc. software Apple's libraries offer different routines. Just use the Cocoa way for example : https://stackoverflow.com/questions/412562/execute-a-terminal-command-from-a-cocoa-app – Jeff Burdges Sep 28 '14 at 16:08
  • Ain't such a big deal but you guys are repeatedly saying things that're technically wrong. You cannot be 100% sure without doing more legwork. Apple might've done that legwork for their servers that remain up with firewall enabled before issuing their statement, but actually I doubt they did even that much. It's probably fine but one should still bust Apple's chops for being so painfully slow to fix their bash itself. – Jeff Burdges Sep 28 '14 at 16:10
  • 1
    I am a Snow Lion user and I see Apple has not planned to do anything for 10.6.8. But I have now paid a visit to System Preferences, which I modified to the most paranoid level in your suggestions. Thank you Jeff. – sharron Sussman Oct 02 '14 at 19:39
2

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.

grg
  • 201,078
Thomas Jones
  • 1,260
  • 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 Sep 27 '14 at 19:35
  • I agree, that's why the source is on https://code.google.com/p/shellshock-check/ – Thomas Jones Sep 28 '14 at 09:44
  • Sometimes though, it can offer ease-of-use for testing multiple systems. – Thomas Jones Sep 28 '14 at 09: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. – Albert Godfrind Sep 29 '14 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. – Thomas Jones Sep 29 '14 at 15:02
  • If you need to check multiple systems, then just use a simple shell script to test the vulnerability, put it on your memory stick, and run it from the stick (just open it to run). – Albert Godfrind Oct 03 '14 at 09:45
  • Then again you may want to check that flash drive for the BadUSB bug (https://srlabs.de/badusb/) :-) – Albert Godfrind Oct 03 '14 at 10:02