In case you missed the news, there’s a big security hole in the bash shell. If you’re using an OS X machine and it’s not exposed to the internet (and even then, not running a publicly-facing service that communicates with bash), you shouldn’t have much of anything to worry about. In theory, anyway.
In practice, because I like to live dangerously, I decided I wanted to make my machine safe. Or at least try. What follows is the how-to for how I did it.
Note: Please exercise extreme caution if you’re going to follow my how-to! I am replacing a couple of key system-level files with a new, untested-by-Apple version. It’s quite possible this may break my system in ways I haven’t yet discovered. Also, given that there’s probably not any exposure for a typical user not running web-facing apps that interface with bash, this really isn’t worth doing for most users.
With that disclaimer out of the way, read on for my how-to…
Avoiding the bash exposure should really only require replacing the version of bash that Apple provides with a more-secure version. However, the reality is more complex than that, because bash is also used as the basic shell (sh is just a copy of bash in OS X). So you need to not only replace bash, but sh as well. And because sh is used by a huge number of OS X’s systems, that’s a potentially dangerous thing to do.
I only decided to proceed with this fix after confirming I had a good bootable clone of my system; with that in place, I was confident I could get my production machine working properly again if I had to. So here’s what I did. Note that the following requires MacPorts to be installed and fully updated; you’ll have to do that before you do anything else, if you’re going to follow me down this risky road. Once MacPorts is installed, here’s what you need to do.
- Run sudo port install bash. This will install version 4.3.25 of bash, but not replace the built-in version of bash. (MacPorts’ ports are installed in /opt/local/bin, so they don’t overwrite the built-in tools.)
- Move the real bash out of the way: sudo mv /bin/bash /bin/bash_old — this keeps the old bad version of bash, but renames it so it can’t be found by scripts.
- Move the real sh ouf of the way: sudo mv /bin/sh /bin/sh_old — again, we keep the old bad version, but rename it so it can’t be found by scripts.
- Create a symbolic link to the new version of bash: ln -s /opt/local/bin/bash /bin/bash — This provides a connection to the new bash in the system-level /bin folder. Any scripts that call bash will now run the MacPorts’ updated version instead.
- Create a symbolic link to the new version of bash to act as the new sh: sudo ln -s /opt/local/bin/bash /bin/sh — This works just like the previous step, but handles any scripts that call sh instead of bash.
And that’s that. Just keep in mind that you’re now using bash version four, which is a much different beast than version three (four linked pages there, so check them all). Some esoteric old scripts may fail; if they do, you can always undo the above steps to return to old unsafe bash, and hope Apple patches it sooner rather than later.
Also note that this much-newer version of bash is now also being used by OS X, for any and all calls the OS itself may make to either bash or sh. That’s where the real danger lies, because I don’t have any idea what all of those calls may be, and whether the new bash is fully backward compatible with the old version.
So far, my machine is working fine—I have powered it down and booted it back up, and everything works. There aren’t any odd errors in Console, either, which is a good sign. But honestly, you don’t need to do this; I did it mainly because I like to experiment with the Unix side of OS X, and I was curious if it would work.
I hope Apple releases a patch in the near-ish future, but I’m not sure it’s iOS 8.0.1 snafu near bending iPhones the nude selfies top U2 album fiasco of their issues list.