Yup, this is what you get when a short-sighted totalitarian government messes with the water cycle to enable farming in a desert, consequences be damned.

Come to think of it, California is what you get when a short-sighted democratic government messes with the water cycle to enable farming in a desert, consequences be damned.

Let's face it, environmental concerns wasn't really on any government's radar until the 70s. (And a lot of countries still try to ignore them...)

No, no, no, no... People really don't get the scope of this.

It doesn't matter what the default user shell is, or what language a CGI script is written in. Bash is the most common system shell, which means it's invoked all the time when other programs run commands.

Obviously, I can't know this, but OP is probably not using csh as his system shell, because that's not POSIX compliant and would cause major breakage.

If /bin/sh is Bash, you're vulnerable, no matter what shell you're using yourself, or what language your CGI script is written in.

Also, CGI scripts is only the most obvious attack vector; others that have been identified so far are the CUPS printing daemon, the ISC DHCP client and locked down SSH shells like those commonly used to host Git repositories. But there are without doubt many more. The only safe thing to do is to upgrade or remove Bash from your system immediately.

No, it's not the CGI program that sets the HTTP_USER_AGENT environment variable, and this is not a vulnerability in the CGI program nor the CGI protocol. The fault lies 100% with Bash, which executes arbitrary shell code from arbitrary environment variables.

Enh, good luck auditing even just a resonably complex CGI program for direct and indirect invocations of the system shell.

For instance, care to guess whether this one is safe?

I know, mod_perl and mod_wsgi on Apache, and of course, Fast CGI. But CGI is still common in a lot of setups.

Even if you don't call out to the shell yourself, the standard library might.

Pop quiz 1: How is the PHP mail function implemented?

Pop quiz 2: What parts of the Python standard library module uuid are safe to use, and what parts will render your CGI script vulnerable?

It's the system shell. It's everywhere. The real lesson here is to not use a big bulky program like Bash as the system shell.

Answers to pop quiz:

1. popen to execute sendmail program.

2. The following Python CGI script is vulnerable: import uuid (that's it). (uuid uses ctypes.util.find_library, which uses popen).

These examples took me less than 20 minutes of grepping to come up with, and I'm not even trying to hack any computers...

Linus didn't use a revision control system for the Linux kernel until 2002.

(Aw... comparisons between CVS and the "soon to be finished" Subversion. How quaint.)

Hm, no, the fault here lies squarely with Bash choosing to interpret an environment variable called HTTP_USER_AGENT as a program to execute.

This is not about accepting arbitrary environment variables; CGI puts data in a few, well-defined variables. This is a perfectly legimiate use of environment variables. (And Windows does the exact same thing.)

You're right that using a "full-bore shell program" such as Bash as the system shell is moronic. It is, unfortunately, still the norm on all major Linux distros except Debian and derivatives (which use the limited Dash shell, which is not vulnerable).

Primarily, I think this is a wake up call for Fedora, SUSE and the others: Bash is a huge, complex component, evidently with insufficient security review, and should not be used as the system shell. Debian dropped it for performance reasons, but now we can add security concerns to the list. It can stay around for use as an interactive shell (though why you'd do that when you have zsh, I don't know...)

Unfortunately, attackers do not share your lack of imagination.

First of all, the CGI vulnerability is not about CGI scripts written in Bash, this is about any CGI script that at any point invokes a shell or invokes a program that invokes a shell (e.g. using the system call), irrespective of the actual shell command, on a system that uses Bash as the system shell (so pretty much all non-Debian based Linux distros).

Got that? any CGI program + any non-Debian Linux => vulnerable. (For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)

Second of all, there are all kinds of non-CGI situations in which untrusted data is passed in environment variables. This is normally not a problem... unless that environment variable at any point is inherited by Bash.

The ISC DHCP client (dhclient) is the canonical example, as it runs a distro-specific shell script to set up the network once it gets a DHCP lease. Unustrusted values from the DHCP server are passed - you guessed it - in environment variables.

If you want answer to "why", go take a philosophy class!

Quid pro quo. I care about them and don't cause them pain; and in return, they care about me and don't cause me pain. It's also called the social contract.

You may argue, "prisoner's dilemma" style, that an individual can then gain an advantage by breaking the social contract, and indeed some people do that. Bruce Schneier wrote a whole book about that topic. But as it turns out, most people don't break the social contract, due to 1) intense social conditioning (religious or otherwise) and/or 2) the threat of punishment if they're caught.

The social contract predates Christianity by millenias; heck, it presumably existed in a primitive form in stone age hunter-gatherer culture.

But even ignoring social conditioning and even the evolutionary traits that have developed to promote that contract (e.g. increased empathy), abiding by the contract still makes sense: Civilization depends on the majority following the social contract, and indeed, most people find that the immediate benefit of breaking the contract is outweighed by the threat of civilization falling apart. Of course, once people start to break the social contract in larger numbers, the cost-benefit ratio changes, and civilization crumbles quickly.

I'd argue that karma is a real thing, only global, not personal. When you do a good thing for others, you increase global karma, ever so slightly increasing the odds of good things happening to you, too. (But it's a big world; I think you'll find playing the lottery has better ROI.)

Personal karma AKA the "just world" belief is of course a myth. The fact that so many people believe in it is a testament to the aforementioned social conditioning.

I mistakingly read this as a response to linear a's post above:

Could be worse. Microsoft originally considered calling it "Bang".

...

I'm not kidding. I guess they liked "Bang" because it conveyed a sense of, uh, instant gratification. Specifically:

Huh? Roundabouts and standard crossings are equivalent when it comes to pedestrians. In both cases, you add crosswalks "circling" the roundabout or intersection, and cars must yield for pedestrians when entering and leaving the roundabout/intersection. (Example of small roundabout with pedestrian crossings and bike path.)

If there's a lot of traffic, you add traffic lights; this, too, can be done for both roundabouts and intersections. (Example of roundabout with traffic lights; though I've personally observed that it's able to carry traffic pretty smoothly even when the lights are malfunctioning. This latter example also has heavy segregation between cars and bicycles; research has shown that cars are unfortunately slighly more likely to overlook bicyclists otherwise, compared to a standard intersection.)

Of course, there's always hideous designs like the Dupont Circle mentioned above, but that's just traffic planners showing that they don't understand roundabouts. Pedestrians should walk around the roundabout, not across it (hence the name), otherwise cars have to yield for pedestrians inside the roundabout, and you get a complete traffic jam. (The whole point of a roundabout is to limit the number of directions in which traffic moves...)

Thank you for this succinct recap of much of this Slashdot discussion thread.

You did forget to mention how the position was "just invented" for her. (And her two predecessors, err...)

In the Copenhagen Metro (driverless), there are emergency brake levers next to every door. However, it was considered dangerous for the train to stop in a tunnel (and have passengers exit through the tunnel). Therefore: If you pull the emergency brake, the train will continue to the next station, then stop. (If you don't pull the emergency brake, the train will continue to the next station, then stop...)

Anyway, this might still be the safest mode of operation. If there's anything rail automation has taught us over the last century, it is this: Whenever the human second-guesses the automation, odds are that the human is wrong. About time cars got to this point, too.

Exactly. Watermarks are useless against general piracy, since the burden of proof is simply too high to take the case against John Q. Public.

For instance, most people don't know that when you buy music on iTunes, Apple puts your e-mail-address in a metadata comment field in the file. But now that you do know, feel free to take a look at The Pirate Bay and start collecting e-mail addresses from AAC files.

Note that it's not a watermark - it's not in the audio data, it's plainly visible in the file and it's trivially removed. Yet the pirates don't even do that. And why should they? I've never heard of a person being even threatened with legal action over this.