First world problems.

You seem confused. Please try reading this thread again, starting with the original post I replied to. Also, the counter-example I provided in my last reply isn't Python. Before opening your mouth to speak, you should probably be reasonably certain you know what you're talking about. Cheers.

You just quoted 106 characters to accomplish the following simple task:

print "Hello, World\n";

That's 23 characters to accomplish the same task, but the core issue isn't even really the character count alone. It's the verbosity combined with the requirement that an object be explicitly constructed to perform something that is a fundamentally procedural task.

n/t

As a side note, if our hypothetical programmer merely examines and untaints $ENV{PATH} in the last example, the exploit will succeed, since Perl doesn't do any taint inspection of a string passed to system() unless it interpolates potentially tainted input. Still, a reasonable programmer would hopefully have an "ah ha" moment after being reminded that $ENV{PATH} is tainted and consider the rest of the environment.

I completely agree.

I don't think you're being argumentative at all. Your points are fair and valid, and I'll note that the specific example provided (per the comments embedded in it) is a bit on the contrived side. That said, Perl actually used to just use whatever it found in $ENV{SHELL} for system() calls, which would have removed the necessity of including the explicit /bin/bash call to trigger the bad behavior, but that behavior was fixed some time ago. Other programming languages and environments may be quite a bit more lax, shifting more of the security burden onto the general operating system environment and further abstracting unsafe lower-level calls away from the programmer.

However, the earlier example is still quite useful for demonstrating another Perl best practice: taint mode. I have seen some truly dreadful things done via shell-outs in various languages, because programmers are of course capable of doing all sorts of very silly and dangerous things in their programs (such as including direct shell binary invocations in system calls), frequently without realizing those things are that dangerous in context. This may be due to the dangers being difficult to anticipate, and this could be said of our first example, as it doesn't contain any code that visibly uses external data. Here's what happens when we turn on taint mode in the initially exploitable script: Perl taint mode saves lives.

If I get the time, I'll be setting up various test environments with an assortment of examples written in different languages and frameworks to demonstrate the sorts of differences described herein, and I'll be glad to keep you posted if you like.

I'm perfectly capable of fixing things myself. That's not the issue here. Try enforcing the policy you described across even a moderately sized multi-tenant SMB computing environment running a variety of applications that you're responsible for managing. You'll soon find that your policy results in negative revenue. The end result becomes a case study in "you broke it, they stopped buying it."

I put together a small example for you.

The Zimbra example is only a single case intended to illustrate the mere existence of #!/bin/bash in scripts on commonly deployed systems; there are many, many others to be found, including wrappers for various commonly used utilities than may well wind up being called from a CGI script. As for your last sentence, you're conflating two concepts. I was specifically addressing the following response: "Certainly not in a distribution which does not have bash as the system shell. You can uninstall bash in such a distribution, and the system is expected to continue running." See the difference?

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.