Macs Mostly Safe from Bash Vulnerability, but Be Ready to Patch
No one is ever excited when a new software vulnerability is revealed, but the disclosure this week of a major bug in a common Unix tool set off an earthquake in the security community. Not only is nearly every version of Unix vulnerable, including Linux and OS X, but most of the initial patches are not completely effective at blocking the hole. It’s a near-worst-case scenario where we have a piece of software on nearly every non-Windows server on the Internet — and plenty of personal computers thanks to Apple’s market growth — that is vulnerable to multiple
kinds of remote attacks, all capable of completely taking over the system, with no way to stop it completely.
Despite the severity, a combination of Apple’s design decisions and how we use Macs dramatically reduces your risk, but you still need to be careful and be ready to install Apple’s next security update.
Shellshock — Bash is one of the most fundamental tools on Unix-based systems, including Linux and BSD, a version of which is at the heart of OS X. By default, when you launch Terminal, Bash is the program that provides the command-line interface. It has been around for decades and is by far the most popular interactive shell.
You don’t need to know the gory details (read Troy Hunt’s write-up if you want them), but in short, a researcher discovered a vulnerability in Bash that enables an attacker to do pretty much whatever he wants. It involves manipulating environment variables sent to the shell when it opens a session. This is clearly a problem if someone gains direct or remote access to your computer, but Bash is so deeply embedded into Unix systems that the vulnerability has some unusual effects.
Many programs hook into a Unix system’s default shell to issue command-line instructions because it’s a convenient way to interact with the computer. It isn’t the safest approach, so those commands are often limited to a low-privilege user account or use some other safety mechanism. Unfortunately, that mechanism rarely involves sanitizing commands sent for bad data, something programmers know they should do, but which can be hard to get right.
Thus we find that many installations of the Apache Web server are vulnerable, as is the DHCP software many Unix systems use to obtain their IP addresses. And those two merely scratch the surface. Passing commands through Bash is such a common technique that we don’t know all the ways it could be exploited, or how easy the exploitation might be. In the DHCP example, simply connecting to a hostile network (wired or wireless) could give an attacker control of your computer. And worst of all, this particular exploit is insanely easy to use — all an attacker needs to do is send a bit of the right text to a receptive app.
For example, security researcher (and friend) Rob Graham ran a partial scan of the Internet and determined Shellshock could be used to create a new Internet worm.
Once Bash is fully patched, the vulnerability should be blocked, but it is also possible there are strange variations that haven’t been found yet. Worse, the sheer number of computers that need to be patched is nearly incomprehensible. Bash is even found in odd places like network devices, appliances, industrial control system components (think your power company), and home automation. On the positive side, not everything is exploitable. It takes a combination of the vulnerable version of Bash and some way to send it arbitrary commands that can be executed in an interesting way. But, to bring you back down again, we don’t know what all those combinations are.
We will be dealing with Shellshock for years.
Why Most Macs Are Safe — As I noted before, all recent versions of OS X have Bash installed as the default shell, and are just as vulnerable as any other Unix-based operating system. However, the default configurations of most Macs appear to block the highest-risk methods of exploiting the Shellshock bug. Unless you set up your Mac as a Web server, or enable some other remote software that could link to Bash, you should be safe. That said, anyone running a Mac server should look into recompiling Bash.
When you’re on your home network, behind NAT (in which your router gets a single IP address from your ISP, and then distributes multiple internal IP addresses to all the devices that connect to it), you’re likely safe. However, when you’re out and about on networks of unknown safety, I recommend turning on OS X’s built-in firewall (System Preferences > Security & Privacy > Firewall > Turn On Firewall). Then click the Firewall Options button and select Block All Incoming Connections. That might be overkill, but it probably won’t affect anything negatively as you use your Mac (it’s how my MacBook Pro is always configured), and it’s easily toggled off and on.
The main vector I was extremely worried about was an attack via DHCP, which could expose your Mac if all you did was connect to a network. To test this concern, I set up my own hostile DHCP server and tried the attack, but to no avail. I couldn’t compromise my Mac, and after asking on Twitter, I found out that Apple uses its own DHCP client, which is safer.
Since we don’t yet understand the full implications of the Bash vulnerability, keep your eyes out for a security update from Apple rather than attempting to patch Bash willy-nilly. (If you run older versions of OS X that no longer receive security updates, you’ll want to recompile your version of Bash, since this vulnerability dates back decades.) But the rest of us should wait for an official update, since the risk to everyday Mac users is low. Apple has already notified the media (including us) that they are working on the problem, and since most of the other fixes are
incomplete, I’m okay waiting a little longer.
What about routers? I read an article saying that they could be affected by the Bash bug. I've not found anything on the NetGear site and I have a NetGear Night Hawk router. (If I call Netgear they will want me to pay for a year of support.)
Thanks
...and I have a Motorola SurfBoard. So, good topic.
I think it's too early to say what the situation will be generally with devices that might have Bash built in, but there's nothing to be done but wait for news from the manufacturers, hopefully with firmware updates where appropriate. Keep in mind that the vulnerability has to expose something, so if the device doesn't have the capability to do that in an interesting way (to lots of bad guys), the fact that it could theoretically be exploited is likely moot.
"anyone running a Mac server should change out to a non-vulnerable default shell"
Okay, which one?
ksh? sh?
tcsh.
For us non-server experts who are running servers, can you give a set of steps on how to do this?
I wouldn't worry about it. As noted below, further discussion indicated that the default shell for a user isn't likely to be involved in an attack. Unless you're running a Web server with CGIs, even a server isn't likely to be attacked.
All that said, I found these instructions for updating bash, which is more what you'd want to do:
http://security.stackexchange.com/questions/68202/how-to-patch-bash-on-osx-in-wake-of-shellshock
Yes, I've got a web server with CGIs up and running. I guess my options are to hope Apple releases an official patch "real soon now"(TM), or try to roll my own. I'm not overly comfortable with either of those options. :(
Ach, sorry. I understand the concern - neither option is great, but hopefully Apple will update soon.
"To be safe, I suggest most of you turn on your firewall (System Preferences > Security & Privacy > Firewall > Turn On Firewall) and set it to block all incoming connections (System Preferences > Security & Privacy > Firewall > Firewall Options) if you aren’t on your home network."
What does that imply — if I want to connect my MacBook to another network when I'm travelling — which is something I do weekly, if not daily — I won't be able to because my firewall is blocking incoming connections? Really, how practical is that?
The firewall is pretty smart. It'll accept incoming connections in response to outgoing connections that you initiated, which comprise 99.99% of average users' internet usage. The one area where this is tricky is SIP clients, although most SIP clients already open a firewall pinhole, which is necessary to traverse a NAT'd device.
IMHO, you should always have a firewall running on your Mac unless you have another good reason for not doing so. It causes little to no harm with quite a benefit.
Is it really going to help much to change a user's default shell? If a program is going to access something through a shell, it seems likely it will specify /bin/sh (a link to bash) rather than running the user's default shell, because it has no way of knowing what that shell's syntax is.
I change my default shell to tcsh all the time just because it's what I'm used to, but what I'd like to know is whether any other shell is compatible with Bourne shell syntax and could be used as in lieu of bash as the target of the /bin/sh symlink.
No, upon further discussion, we've come to the same conclusion, that changing the user's shell isn't likely to help, so we've changed that recommendation. If you run a server accessible to the outside Internet, you may wish to recompile Bash.
"If you run a server accessible to the outside internet"
I assume this includes "ssh" not just web or DHCP server?
If so then many Mac users might have "remote login" turned on via checkbox and be vulnerable?
A Web server is the most likely to be attacked at this point, I think, but there are no guarantees if any services are available to the outside world. :-(
If so then many Mac users might have "remote login" turned on via checkbox and be vulnerable?
this has not been emphasized enough in the various discussions. I bet many users will not realize this is a "server"
What about VNC, Apple file sharing, SMB?
I've seen concerns about SSH as well (from Cornell University's IT department), but this is beyond my Unix knowledge. For more, see:
http://unix.stackexchange.com/questions/157477/how-can-shellshock-be-exploited-over-ssh
I suspect that most Mac users aren't at risk because they'll be behind a NAT gateway with very few ports opened to the outside. The quick protection would be to close those ports.
from stack exchange:
"The vulnerability comes into play if the account is restricted to run specific commands: for example, an SFTP-only account, or a git-only account, etc.
There are several ways to restrict an account to run a specific command with SSH: with the ForceCommand option in sshd_config, or with a command=. restriction in the authorized_keys file. If the user's shell is bash, then the Shellshock vulnerability allows a user who would normally have access only to the restricted account to bypass the restriction and execute arbitrary commands."
I could not see clear evidence that there were such limited accounts on my machine, but not sure I know how/where to look completely, do you know if the operating system creates such limited SSH accounts under any normal circumstances? Rich?
On a quick and dirty look I did not see any and even created "share" only accounts to see, and it seems that OS X SSH will only allow access to admin accounts, not "share only" accounts, again very quick and dirty check.
And the update is out from Apple!
http://tidbits.com/article/15115
I'm keeping track of the Bash CVEs and Apple's ongoing patchfest at my Mac-Security blog:
http://mac-security.blogspot.com/2014/09/coverage-of-apples-bash-shellshock-bugs.html
In summary: There are currently (at least) 6 known Bash CVEs. (CVE stands for Common Vulnerabilities and Exposures. It is a catalogued listing of specific security bugs found in public software). Apple patched 2 of those CVEs today. There are the remaining 4 to go, plus any further CVEs discovered. One of the six CVEs remains published but not yet described. This typically means the CVE does not yet have a patching solution. No description is provided in order to thwart exploits.
I'll be updating the CVE list and links as Bash patching progresses.
Let's move the discussion of the patches over to that article at http://tidbits.com/article/15115