Because of CVE-2014-6271 and CVE-2014-7169 on OS X I was wondering: can bash be replaced entirely by another, non-affected shell (eg dash or others)?
First, you don't need to do this unless you are are offering web services to the public internet from your Mac. If you are not, wait until there is an official security update from Apple.
However, if you are offering web services, you might want to update.
Apple has released an Official Bash Security Update Here
Checking whether you are vulnerable
First confirm that you are using an outdated bash:
$ which bash /bin/bash $ /bin/bash --version GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc.
The most current bash is 4.3.25
If you don't have Xcode installed, you'll need the Xcode command line tools, which can be installed by
$ xcode-select --install
Or from the developer portal.
To install Brew (http://brew.sh):
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ brew doctor
Follow any instructions if there are problems. Many common problems are addressed here.
Then update brew to the latest list of packages:
$ brew update
To get the latest bash 4.3.25:
$ brew install bash
This installs bash into
sh still exists at
/bin, so after installing you'll rename the old executables to a new file.
$ sudo mv /bin/bash /bin/bash_old $ sudo mv /bin/sh /bin/sh_old
If you are very paranoid, you can remove execute permissions on the
$ sudo chmod a-x /bin/bash_old /bin/sh_old
Then create a symbolic link to the new bash 4.3.25 that brew installed.
$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/bash $ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/sh
Reboot and it is complete.
A warning — this may break some existing shell scripts that might rely on bash 3.2 or the differences that the Mac
sh has over the linux
sh. There is a much more sophisticated answer to replacing bash and sh from sources in this post.
In most cases it is best to wait for official updates.
As @webmarc said, no. You can replace
/bin/bash with some other shell but you will certainly break some programs because bash has several differences in his syntax that made it incompatible. I couldn’t find a bash-compatible alternative shell. However I symlinked dash to
/bin/sh and found no issues so far.
Regarding the DHCP here there is a proof of concept attack.
The article is about
dhcpcd (a Linux client). I’m not sure about Mac OS X. In the discussion on Hacker News they say OS X client doesn't use bash at all.
Another vector could be
sshd. But the attack require authentication. So, unless you are running some ssh service like a
git server you should be safe.
dash contains only a tiny subset of the commands found in
bash and even
sh (which itself is a sub-set of things in
bash). Replacing either with
dash will surely yield inoperable scripts on your system and possibly break your system more than it protects your system.
You can recompile bash to mitigate some (at the time this was written) of potential danger or wait for Apple to release and official fix.
some sites indicate one could be infected via a DHCP client.
This does not apply to OS X. On Linux systems, a shell script is usually called after receiving a DHCP lease from the server. This is not the case on OS X.
Unless you're running a web server on your Mac which serves CGI scripts, you have little reason to worry.
Yes, if you mean as /bin/sh, but it could be problematic, but if you want to replace bash as /bin/bash or remove bash entirely, basically no, though it's not impossible --since, scripts are text files, you could edit every shell script, and then maintain the system yourself, by yourself, for the rest of time... There is no drop-in-replacement for bash.
Not, that you replacing /bin/sh would easy, but there could be an end to it. If a script presumes your /bin/sh , is actually bash, and uses things unique to bash, then script that begins #!/bin/sh would now break. I renamed my /bin/sh to /bin/sh.was.bash and then made sh a link to mksh , and rebooted was greeted with a the # prompt. I rebooted again with verbose flag, and found a few lines into /etc/rc -- export -n, a bash thing, the korn shell equivalent is typeset +x, I modified the rc script, and, and it booted up, and w/ everything good. The system I'm experimenting on is Tiger so there's a rc script, and I can expect no updates from Apple. Modern OSX doesn't have a rc script, BUT modern apps might go from intel linux , where /bin/sh is bash, to intel-mac, where /bin/sh is also bash, and a developer could just as easily add bashisms to launch daemons and launch agents, and if not right now, but later when they rush out an update (for their app), which will now will only break on your system.
So, perhaps I should say very problematic, because you should take it as a reason, NOT to do this. In my defense, I've been poking around with launch daemons, and the rc scripts, this week and the week before, playing with dynamic_pager options, turning off a few launch daemons (making them controllable by variables in hostconfig ), so for me, this I just an experiment just a little bit more radical, than I might have done today, anyway.
IF you want to do something, if think you might be more vulnerable than others, because of additional software, etc, you could look at each script that you're concerned about, and change the the first line (the shhbang) to do something other than #!/bin/sh or #/bin/bash, and be prepared to do edit the scripts, since they could have bash specific features. BASH is really a korn-shell like shell, more than a bourne-like shell like ash, or dash, so if want to keep edits trivial use a korn shell as a replacement. IN fact on tiger /bin/ksh is the "NEW Korn Shell", if this is still true, I'd say go with that, then you need to install nothing, and leave /bin alone, which isn't a bad idea, just change the scripts to #!/bin/ksh, remove bashisms for features, common to korn shell, but you could luck out and there would be none.
There is a chance, that 'shhbang' could be ignored, since it is if a shell script is invoked like "/bin/sh /etc/rc", then the first line is just a comment, and ignored, but with this approach you can only break the things you change, as you change them.