Or "I don't run UNIXes that default to bash, or hide it under /bin/sh, etc."
Unfortunately, bash shows up in surprising places, including default Solaris installs nowadays.
On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. I'll put more effort into establishing its acceptability as a solution tomorrow.
BSDs won't have bash unless someone has gone out of their way to install it, which can be undone straightforwardly.
But it could be a long night for our Linux brethren and sistren.
Good luck, and remember to stay hydrated. :)
EDIT: obviously, don't chmod 0000 your login shell! Fix that first. Make sure whatever you switch to isn't a symbolic or hard link to bash.
> On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far.
In the case of OSX, /bin/sh is also bash. For some reason they are separate binaries (at least on my laptop running 10.9.5) but they're both really bash inside:
$ ls -ld /bin/sh /bin/bash
-r-xr-xr-x 1 root wheel 1228240 Sep 21 21:37 /bin/bash
-r-xr-xr-x 1 root wheel 1228304 Sep 21 21:37 /bin/sh
$ /bin/sh --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
$ /bin/bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.
So even if you chmod bash to 0 you could still be exposed by anything that uses /bin/sh -- system(), popen(), most shell scripts, etc
(ETA: as I've mentioned elsewhere in this thread most people running OSX probably aren't badly impacted since they're not running CGI-based web software or other high-risk activity. I'm just pointing out that your bash-ectomy of OSX isn't as complete as you think it was)
You and Thomas can ignore everything I say about security. J. Random Rails Developer, on the other hand, probably gets useful signal if I start panicking. (Am I panicking? YES.)
I guess it comes down to how you interpret things.
I specifically said any decent shell script. My logic is that if it is not using "sh", but instead relying on bash (or any other specific shell really), it's not a decent shell script.
If I were to amend the sentence to make the meaning clearer, I would still not use "should be", I would use "must be".
You're overreaching. I write scripts against bash, not sh, because it's a better scripting language for what I need. It's more readable and its constructs are easier (for me) to follow. I don't care about POSIX-compatibility when bash can be installed literally anywhere. It's a dependency for the devops stuff that I run and maintain, much like Ruby is a dependency and all the gems in my Gemfile.
It's a considered decision, not a sign of "indecency".
If you can confidently assert that every shell script your system runs is "decent", then you'll have no problem. The thing is, very few of us can confidently make that assertion.
That all depends where your shell scripts come from.
In my experience most of the shell scripts provided by packages for debian, do use /bin/sh.
A quick check of .sh files on a couple of squeeze/wheezy installs showed that the vast majority of shell scripts using Bash come from node modules, which quite frankly is not surprising.
There is tremendous range in what a "shell script" might be. I vastly prefer bash to sh as a user shell. Often times, I have bits of logic I express in a command that I want to capture and reuse, and they get grabbed and dropped in a (frequently context specific) bin directory. I would contend that these "save me from typing it out" shell scripts should mimic what I would type myself. Once they wind up being more general, I usually rewrite them in a different language entirely. That's a very different context than something like an init script, though.
Yes, but Debian and Ubuntu has changed their default shell to Dash (in 2006 I think), and embedded systems usually use some lightweight shell such as BusyBox. So far from all systems do.
Someone is going to be going through busybox soon, and then there (potentially) will be a whole bunch more exploitable boxes that don't have a generally have a regular update cycle.
You're right, of course. Exploitable weaknesses in busybox are going to be killer - I think shellshock will turn out to be the start of something really big.
But, to clarify for others, the existing shellshock PoC doesn't work on the busybox environment I tested (v1.20.2).
As you well know, as long as your system doesn't use bash for anything, even implicitly :)
Many folks are thinking that just because they switched their user's login shell to 'ksh' to be one of the cool ruby kids, that they're safe.
Unfortunately, bash shows up in surprising places, including default Solaris installs nowadays.
On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. I'll put more effort into establishing its acceptability as a solution tomorrow.
BSDs won't have bash unless someone has gone out of their way to install it, which can be undone straightforwardly.
But it could be a long night for our Linux brethren and sistren.
Good luck, and remember to stay hydrated. :)
EDIT: obviously, don't chmod 0000 your login shell! Fix that first. Make sure whatever you switch to isn't a symbolic or hard link to bash.