41

I've recently heard via Twitter about CVE-2014-6271.

Are ordinary OS X desktops, that aren't acting as a web server, at risks of receiving attacks that could exploit this vulnerability?

3
  • 20
    For those who don't spend their time memorizing CVE numbers, this is the recently-announced bug in Bash where exported environment functions aren't handled properly.
    – Mark
    Sep 25, 2014 at 1:03
  • 4
    Premature accept, it seems. DHCP looks vulnerable. Sep 25, 2014 at 10:55
  • nm -a /usr/libexec/bootpd | egrep '(exec|popen|system)' doesn't exhibit any call to a shell on versions 10.7 to 10.9. Hence DHCP isn't vulnerable to this attack.
    – dan
    Sep 30, 2014 at 7:33

3 Answers 3

35

Define "risk".

The core of this attack is to create an environment variable that looks like a Bash scripting function but ends with the invocation of a program, and then cause Bash to be run. Bash will see the environment variable, parse it, and then keep parsing past the end of the function and run the program.

Any method of triggering Bash execution with at least one attacker-controlled environment variable will work. Web server CGI attacks are getting the attention right now, but a user logging in over SSH could do it (a failed login, however, can't). It's possible that some FTP servers could trigger it (say, through running a post-upload script). A PackageMaker-based installer could trigger it, but if you're running a hostile installer, you've got bigger problems than this. There are probably many other ways as well.

The average desktop user doing average desktop user activities is unlikely to have open attack vectors that could be used to trigger this bug, but Bash shows up in enough unexpected places that it's impossible to say for sure.

8
  • 8
    If a user logs in via SSH, don't they already have access to a shell? What would this exploit give them that they wouldn't already have? Sep 25, 2014 at 5:32
  • @AlexisKing There are countless things (such as CGI) all around us that basically operate on a shell in the background. Now, the user can execute arbitrary code on those.
    – Joost
    Sep 25, 2014 at 5:57
  • 10
    @AlexisKing, It's possible to restrict which commands a user can run via SSH. Since those commands are run through the user's login shell, this can be used to bypass the restriction.
    – Mark
    Sep 25, 2014 at 5:57
  • 1
    @Mark you would still have to have Remote Login enabled, and the attacker would need a username and password. The CGI vectors are more troubling, I use mod_php for all my web pages, but OS X server puts up a huge number of HTTP endpoints many of them using Python, so I'd say there's risk there.
    – alfwatt
    Sep 25, 2014 at 19:28
  • I think the execution of shell scripts by the OS X DHCP client is the biggest potential risk for Mac clients - an rogue WiFi hotspot could execute code on your Mac.
    – RichVel
    Sep 26, 2014 at 4:47
11

What you'd need to do is determine which processes are running bash. On Linux systems, one vulnerability seems to possibly be in how DHCP requests are handled.

You could look at using execsnoop to spot what runs bash and then try doing some normal things - like connecting to a wifi network or browsing webpages that require external helpers (say something like iTunes). See if bash is run and then use some other dtrace tools to see if you can inspect the environments.

However, to be honest, it would make more sense just to update your machine as soon as a fix is available. I haven't seen one yet for OS X (but haven't looked for a few hours), but I'd keep an eye out and update when that happens.

0
8

No, as far as I can tell, ordinary OS X desktops are not.

OS X DHCP is not vulnerable. These days it doesn’t even invoke a shell at all, and in the versions that used a bootpd that did invoke a shell, that shell was not Bash; some sites have suggested that it would have been tcsh that was executed, but I think it would actually have been /bin/sh, which (from memory) on older versions of OS X was BSD’s implementation of the Bourne shell, not Bash.

If you are running Apache and you are using vanilla CGI (which is not normal for an OS X desktop) with Bash, you are vulnerable.

Likewise if you are using an OS X machine to run a restricted SSH server using ForceCommand, you are vulnerable. Again, this is not normal for an OS X desktop.

As for Apple’s various server processes, while I haven’t checked all of them, from memory they tend to use Twisted and then reverse proxy them using Apache. That doesn't involve CGI and isn't vulnerable.

1
  • This is the best answer! Surprised the other answers got so many up votes.
    – paj28
    Sep 28, 2014 at 12:48

You must log in to answer this question.

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