I'll add a note that a couple of network daemons I've recently authored are designed to be started under any given shell, including Bash, but they also communicate over raw TCP sockets instead of CGI, get exec-ed into a shell with an explicitly blank environment (blank as in "no environment vars are set whatsoever"), chroot themselves to a safe filesystem with noexec specified for the mount, drop privileges to "nobody" (again, with no env vars available and hence nothing for the shell to parse), mlock their process memory, and run under Perl's hard taint mode which requires regex whitelist examination of any externally supplied data before it may be used by the process. Optimally, these daemons should be run under a grsec kernel that provides additional protections, including making chroots far more bulletproof than they normally are under Linux, but I don't hard fail for lack of that.

The trouble is simply that most developers don't think about these things.

In terms of the ratio of Linux distributions which use Bash as the default shell versus those that do not, the vast majority still use Bash. As I mentioned earlier, Debian-based distributions use dash as the default system shell, but Bash remains the default interactive shell, and many scripts specify #!/bin/bash in their shebang line.

That last bit is important, because we're living in times where an increasing number of developers are releasing code for network daemons which are designed to be easily run under unprivileged user accounts by those same users. Regardless of how secure the daemons themselves may be, the simple fact that they're executed with Bash as their parent process means they're vectors for system compromise from bugs like Shellshock. Should developers take additional measures to spawn their processes under a different shell? Perhaps, but only if problems like Shellshock are known, and should a similar bug be discovered in the true Bourne shell (or whatever else), we'd still be in the same position.

The karma bonus posting option is enabled by default for a reason. When people who have an established track record of saying meaningful things (as determined by the up-modded metric) post comments, those comments are automatically ranked higher. Likewise, the moderation system provides for down-modding of any given comment, which has the side effect of karma reduction for the "offending" poster. The fact that you don't like what someone has to say is really of little consequence unless you have mod points; this is by design.

Let's get a few things straight in terms of my perspective on this whole ordeal. Most of my infrastructure runs on Debian, and the remainder runs on FreeBSD, OpenBSD, and Solaris. I understand your sentiment in feeling offended at this situation being labelled a "Linux problem," and I think the original poster is a positive dickhead for what he wrote. That said, I recognize that the reality of the situation is that around the globe, most of the systems affected by this bug will be Linux-based servers. There's no escaping this fact, as unfortunate as it may be. Given these circumstances, it is very much a "Linux problem," regardless of the fact that the kernel isn't to blame.

For a little perspective, I do infosec for a living (spending a fair amount of my time developing exploits from scratch, in fact), and I'm a senior guy who is intimately involved with promulgating guidance for rapidly patching a ridiculous number of servers against this sort of problem across several datacenters spanning multiple continents. It sucks, but software isn't perfect. We do what we have to do in situations like this and keep moving.

Various common software packages explicitly specify #!/bin/bash in their init (and other) scripts. This is done to prevent problems in cases where the scripts in question must be run under Bash, in recognition of the facts that (1) /bin/sh may be arbitrarily remapped/diverted to any number of shells by system administrators, and (2) alternate shells such as dash are not 100% compatible with Bash.

As a simple example, the shebang line for Zimbra init scripts is #!/bin/bash.

Shellshock isn't really about elevating user account privileges (although that's certainly a common goal once unprivileged shell access is obtained). It's about gaining the ability to execute arbitrary commands as the user a Bash shell is running as. This is particularly bad for systems where the default system shell is /bin/bash, but it's also very bad for systems where users may be running network daemons under a normal user account. This is more common than you might think; developers frequently run things like node.js, various Ruby servers, etc in this manner. In the worst case event that /bin/bash is the default system shell, accounts such as "www-data" or "nobody" will likely use this shell for CGI request handoffs, meaning any input passed through CGI represents an opportunity to send a special payload down the pipe for execution in the context of that user account.

While Bash isn't the default system shell on FreeBSD (nor is it even installed by default), I certainly hope you're at least using "pkg audit" with things you install from the ports collection, as package signing is only just now available with pkgng and it isn't required. If we're going to have a discussion on things related to security, these points should probably be brought up.

Please explain how scripts which specify #!/bin/bash on the shebang line are going to use something else. An awful lot of scripts have that as their first line.

Please reference the output of "echo $SHELL" in your terminal. Unless you've changed it, Bash (via /bin/bash) is still your default interactive shell. You can change your shell if you like.

Part of my last comment was actually wrong, but you probably won't like the reason it was wrong. While Debian and Ubuntu use dash as the default system shell, Bash is still the default interactive (login) shell. Reference the output of "echo $SHELL" at a prompt on a vanilla Debian or Ubuntu server. I'm sure you'll appreciate this, as I agree it's always important to get our facts right. Cheers.

Wrong. The difference is clear, but it's also clear you lack any semblance of understanding that terms have implications depending on context. Please tell us all how many Linux-based systems you operate that run only a bare kernel.

Wrong. While Debian and Ubuntu (along with various other Debian derivatives) ship with dash as the default interactive shell, here's a nice (non-exhaustive) list of highly popular distributions which use Bash as the default:

• Red Hat
• Fedora
• openSUSE
• Mageia
• Arch
• Slackware

Who cares about that?

Wrong. It's not personal, really. I don't care who you are, but I do care that you made an overt attempt at muddying the waters by acting in an overly pedantic fashion, when said pedantry was clearly in error given the context of the discussion. You can always phone RMS up if want to have a nice "omg yes Linux is not GNU and GNU is not Linux" conversation. That particular point has no value in this context, as the discussion here is on complete operating systems, not bare kernels.

My facts are in order. Are you tired of digging yet? You can always put down the shovel.

Some environments do indeed link /bin/sh to a shell binary of choice. Others use things like dpkg-divert (Debian-based systems) to manage which binaries get run for certain commands, and under FreeBSD default shell selection is typically accomplished via "chsh -s /usr/local/bin/whatevershell" after installing the desired shell (probably via the ports collection). What was your point again?

Please elaborate. I'm deeply troubled by the possibility that my understanding of BSD-based systems might be flawed, since I've been operating a significant amount of infrastructure based on OpenBSD and FreeBSD for over a decade.

No, you're incorrect, and you're making yourself look worse now. Put down the shovel. Let's review, starting with your original post:

An "OS" (operating system) is more than a bare kernel, at least for the systems being discussed in this scope, and this is certainly the case for the overwhelming majority of general purpose computers on our planet. "Linux" in this context refers to operating system distributions which include a Linux kernel and various assortments of userland software, much as FreeBSD/Mac OS X/Windows/etc consists of a kernel and other software. Operating systems do indeed have a concept of a default shell, and this may be expressed as simply as a filesystem link from /bin/sh to whatever program is designated as the default, or it may be a default in another sense such as the default shell assigned to a user account upon its creation if no particular login shell is specified.

The default installed set of software (the "applications") will vary between distributions, and if a vulnerable application (Bash in this case) is not installed, the server running said operating system environment cannot be exploited via any vulnerabilities which may exist in that application. If an administrator chooses to install a particular bit of software, the system then may become exposed to security vulnerabilities in said software, but the important distinction being made here is that computers are not vulnerable to bugs for software which isn't installed. Most popular distributions Linux systems install Bash by default, and it is frequently the default shell.

This is really very simple. Are you still having trouble with comprehension? I suspect you may be attempting to act in a pedantic manner here, but you're doing a poor job of it if that's the case.

You're incorrect. The default shell is tcsh on FreeBSD, and bash isn't even installed by default.

I'm working on some rather large scale parallel network operations, btw.

I suspect we'd get along pretty well. Hit me up if you're ever in Dallas, TX.