Update November 14, 2014: A new possible vector of attack involving DNS responses has been disclosed (CVE-2014-3671). At this time it is unclear which (if any) native applications could be affected by this. To use this mechanism of attack, an attacker would either need to cause the user to connect to a specific DNS name, or be able to intercept and modify DNS responses. Systems that have the previously mentioned patches applied will not be vulnerable to this new attack vector. It is recommended that all users apply the patches for the Shellshock vulnerability to ensure that they are not affected by this, or any future attack vectors
Update: Apple has released patches for Bash in OS X. Testing confirms that this patch resolves CVE-2014-6271, CVE-2014-7169, CVE-2014-7186 and CVE-2014-7187.
Since it was announced yesterday, there has been a huge amount of attention given to the “Shellshock” (CVE-2014-6271) vulnerability. This vulnerability affects the Bash shell application, which is used on a wide variety of unix-style operating systems. Given the widespread adoption of these operating systems by device and computer manufacturers, there has been a lot of speculation as to what exactly is vulnerable, and what is not.
In order for this bug to be successfully exploited, two conditions must be met:
1. A vulnerable version of Bash must be present.
Versions up to and including 4.3 are vulnerable. An initial patch was released to address CVE-2014-6271 however it does not fully resolve the problem. The newly discovered issues have been assigned to CVE-2014-7169, and a patch for them is still pending.
2. The system must pass external input as an environment variable to a Bash script.
The attack surface of this vulnerability is severely limited by this second requirement. Typically only authenticated users will have access to the Bash shell interpreter (after all, its used to provide shell access to a system!). It is primarily how other applications interact with bash that will leave a system open to attack or not.
Unlike Windows, since OS X is based on FreeBSD, it has Bash preinstalled. As shown below, we have confirmed that the latest version of OS X (10.9.5) is vulnerable to this issue:
The second requirement however is that there needs to be some way for an attacker to actually take advantage of the vulnerability. The Redhat security team did a great job of describing some ways that this could be done in a recent blog post and advisory.
The most accessible attack vector is to target a web server. Out of the box OS X does not run any web servers, and it is unlikely that a user would install one. As the Redhat team notes, it would need to not only be a web server, but one that also runs and processes Bash-based CGI scripts.
Among the other mechanisms that are likely to be open for attack, both the DHCP client and the CUPS service are included in a standard install of OS X.
The Linux version of DHCP is vulnerable due to the fact that the dhcpclient application calls a number of shell scripts whenever it is run.
To ensure that our test setup was working correctly, we first targeted a Linux system. We were able to confirm it would be possible to gain remote root access on Linux by targeting the DHCP client using the Shellshock vulnerability.
Next, we performed the same test against an install of OS X Mavericks. The test used was to simply write to a file in /tmp, confirming that our command was being executed. Despite working flawlessly on Linux, OS X was found to be impervious to this attack.
This is not too surprising, as OS X uses a custom DHCP client which is written by Apple. While the Linux DHCP client makes calls out to Bash scripts with the data it receives, the OS X DHCP client does not. This has since been confirmed by other researchers who also looked into this issue:
The Redhat team also mention that CUPS is a likely attack vector. This is due to how the environmental variables are passed to the CUPS filter scripts.
OS X includes a CUPS server by default, and even comes with a web interface which is partially disabled by default. This interface does not run any Bash scripts, but instead runs compiled CGI applications.
Currently there are no public PoC’s showing how the CUPS filter scripts can be exploited. All the filter scripts included by default in OS X are compiled binaries, so it is not clear if they would be vulnerable in the first place. We are continuing to look into this area further, but it currently does not seem to be vulnerable on OS X.
With both DHCP and CUPS out of the way, there is little that a remote attacker is likely to be able to target on an OS X system. A local attacker however may still have options. Instead of being limited to remotely accessible applications, a local attacker (or local malware) could target any application.
The main goal of a local attack would be to escalate access. Any application which exports shell variables to Bash would be vulnerable, and any SETUID flagged application would allow for privilege escalation.
A quick review of SETUID applications included with a fresh install of Mavericks did not uncover any vulnerable applications. That said, there are a huge number of third party applications that are likely vulnerable. It has been confirmed, for example, that VMware Fusion is vulnerable to this issue, and allows for privilege escalation.
Out of the box, iOS does not ship with a copy of Bash. Since the first requirement to this vulnerability is that a vulnerable version of Bash is present, by default all iOS devices (iPhones, iPads, etc) are going to be safe.
Before you feel too comfortable about things however, keep in mind that all jailbroken iOS devices do come with a copy of Bash. It is worth noting that over 20 million iOS devices are jailbroken, so they should not be ignored out of hand. A quick test showed that the version on my test phone was indeed vulnerable:
Unlike Linux or OSX based targets, there are very few services commonly running on iOS devices that might be open for remote attack. The primary one is DHCP, with almost everything else being restricted or not even present.
As with OS X, an attack vector to actually make use of this vulnerability is still required. Once again we ran the malicious DHCP server to see if this device would be vulnerable. Similar to before, the test command was not executed, and no files were written.
It would have actually been a little bit surprising if this attack did work, as iOS devices don’t usually have a copy of Bash installed. This means that the DHCP client that ships with iOS devices would never try to interact with Bash as it would not be the installed shell interpreter. It is possible that jailbreaking could change the default shell interpreter, but the test confirmed that iOS devices are still not vulnerable.
There appears to be a lot of confusion as to what other devices and systems are vulnerable. While a huge variety of devices are going to be affected, there are some that definitely are not.
Android based devices
While Android is based on Linux, it does not actually make use of the Bash shell interpreter. Instead it uses Mksh (or Ash on very old versions), which is more limited in functionality, and importantly, not vulnerable to Shellshock. So Android users, whether rooted or not do not need to be concerned about this vulnerability.
Internet of Things
The majority of consumer embedded devices run some version of embedded Linux. This includes everything from your wireless router, to your thermostat, to your light bulbs (possibly!). While these devices are often full of vulnerabilities, they are most likely not vulnerable to the Shellshock attack despite what the news is currently reporting. This is once again due to the fact that these devices do not come with Bash, but rather a much smaller shell interpreter known as BusyBox. Without a copy of Bash installed, this vulnerability simply does not exist.
It is worth noting that some embedded devices will run a full version of Bash and as such be vulnerable to this attack. Shellshock will indeed be a serious concern for those devices, even if they are less common.
While many devices and systems will be vulnerable to Shellshock, there are a limited number of ways to remotely exploit this vulnerability. Our research has showed that iOS and Android devices, as well as many embedded devices are completely unaffected by Shellshock. Systems running OS X are not likely to be vulnerable to a remote attack, but a local privilege escalation attack may be possible. As always, both users and server administrators should still apply any available security patches for this issue once they become available.