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.

Official Patch

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)"

Then do:

$ 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 /usr/local/Cellar/bash/4.3.25/bin/bash

The old bash and 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 bash_old

$ 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.

  • 2
    “In most cases it is best to wait for official updates.” Unless someone is running a server, none of this is really necessary. Many folks will be breaking their OS X installs in the next few days as they panic to neuter a threat they barely understand. – JakeGould Sep 25 '14 at 21:50
  • 1
    @JakeGould — I agree. – Christopher Allen Sep 25 '14 at 22:02
  • I would copy the files instead of linking -- if for some reasons, you remove the brew installation, your system has a problem.... – Michael_Scharf Sep 26 '14 at 12:56
  • 1
    I think apple.stackexchange.com/a/146851/83347 is the better answer, because it uses sources form apple.... – Michael_Scharf Sep 26 '14 at 13:11

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.

  • “In the discussion on Hacker News they say OS X client doesn't use bash at all.” Where is this discussion? You should provide a link. – JakeGould Sep 25 '14 at 23:34
  • 1
    @JakeGould The link is already in the answer. Read the comments. – Rnhmjoj Sep 26 '14 at 4:39

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.

Unfortunately, no... various shells have differing syntaxes making the scripts written for one shell possibly incompatible with another shell.

I haven't seen the DHCP based infection you're speaking of, can you provide a link in your question?

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.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.