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?

Deer Hunter
  • 5,297
  • 5
  • 33
  • 50
Andrew Grimm
  • 2,100
  • 2
  • 20
  • 27
  • 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 '14 at 01:03
  • 4
    Premature accept, it seems. DHCP looks vulnerable. – Deer Hunter Sep 25 '14 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 '14 at 07:33

3 Answers3

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.

Mark
  • 34,390
  • 9
  • 85
  • 134
  • 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? – Alexis King Sep 25 '14 at 05: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 '14 at 05: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 '14 at 05: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 '14 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 '14 at 04:47
  • @RichVel, To the best of my knowledge, OSX uses its own DHCP client rather than the ISC DHCP client, and so is not vulnerable to attacks from rogue servers. – Mark Sep 26 '14 at 04:53
  • AFAICT none of the vectors suggested by which a machine could be attacked would work on on *ordinary* OS X desktop system. You need to do things that are decidedly *not* ordinary to make the machine vulnerable (like running CGI scripts, relying on SSH’s `ForceCommand` or running an FTP server with a post-upload script). – al45tair Sep 26 '14 at 09:54
  • Almost nobody used ssh's ForceCommand, and you'd need to know the ForceCommand, so probably not even worth mentioning. There are however a fair number of web developers using local CGI scripts. And various tools like ownCloud, FreeNet, etc. use CGI scripts to provide a user interface. Not the average user, but still lots. – Jeff Burdges Sep 26 '14 at 22:37
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.

Kevin Lyda
  • 211
  • 1
  • 5
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.

al45tair
  • 236
  • 1
  • 4