Then call it a CentOS or Ubuntu bug. There is nothing intrinsic to Linux, itself, that make is any more or less vulnerable to this *bash* bug.

It's Ubuntu, so whatever their market share is. 12.04 if you want to get specific.

It is also an OSX bug, an HPUX bug, a vxWorks bug, and, well, really, a bug in any OS that has bash installed, which makes it a Windows bug in a not-insignificant number of cases, as well. Also, consider that the thousands of Cygwin and MinGW users out there are also likely running servers on top of that POSIX layer on their windows system, they're almost certainly vulnerable.

And the moment they use a found exploit, some dedicated sysadmin detects the intrusion and figures out how it was done, a bug report is filed, and it gets patched within hours. Like this bug, found by a researcher, reported, and patches were available before exploits; whether or not systems were actually patched is a factor if the sysadmin responsible for each individual system, but the fact still remains that we didn't have to wait until Patch Tuesday for a fix.

Was the first patch complete? No. Nor was the second. The third may well not be, either, but Patch Tuesday still hasn't come around and we're better-patched than those who have to wait for that. Well, aside from OSX users (myself included), who actually paid for their OS (in the form of a hardware purchase), so yeah, I guess "you get what you pay for" holds true here, right? See what I'm getting at, here? Linux users have a steady stream of patches already available to install, for free, while OSX users are left behind by Father Apple. Well, at least *some* of us can compile our own patched replacements, so I'm still not sitting here waiting for Patch Tuesday to fix this.

That being said, I haven't had to reboot my Windows machine for updates, lately. That might be, in part, because it does so automatically, whether I'm there to save my work or not, and regardless of whether I'm in the middle of a multi-day render that I'll have to restart, losing 4 days of progress. Thanks, Microsoft.

Do you have a copy of the bash source code in which this bug was first introduced? There is no versioning going that far back for bash, so you can't possibly know *when* it was introduced. It's quite possible that it's from 1989, when bash was first created, 2 years before Linux came to be.

So do OSX, HPUX, and just about every other UNIX variant out there, as well as BSD and any number of embedded systems, and any Windows install running a POSIX layer. It's a POSIX issue, by way of bash being common amongst POSIX systems, not a Linux issue. Focusing on Linux as a means to be able to say "hey, look, Linux fucked up" serves only to mask the existence of the vulnerability in the vast majority of systems *not* running Linux but also running Bash. For the sake of security, as a whole, please, don't do that.

Well, yeah, if your distro symlinks /bin/sh to /bin/bash, which not all do. In fact, you can install sh, zsh, dash, or any other shell, alongside bash, even on systems that symlink to /bin/bash by default, completely negating your entire point. Looks like you did that on a fedora-based system? I'm going to guess RedHat or CentOS? Observe (from one of my production systems):

ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Mar 29 2012 /bin/sh -> dash

My production (and development, for that matter) systems are not vulnerable in that manner, because I didn't configure them like a jackass; in fact, any init scripts on those systems requesting a shell other than /bin/sh (that is to say, those requesting /usr/bin/php, /usr/bin/perl, or some other interpreter were left alone) were altered to use /bin/sh with no apparent ill consequences.

My point is that this is not a Linux bug, it is a bash bug. Bash is used on HPUX, amongst many other UNIX variants, up to and including OSX, as well as many, if not most (or all) Windows POSIX layers. Your cable or DSL modem probably has bash running on it somewhere, FFS.

Technically, it would be a bug in any script starting with

#!/bin/bash

having absolutely nothing to do with Linux.

The ability to drop the GUI and slim the system down to run on a machine with very limited resources, while still having a full system (e.g. not CE) is a significant benefit over Windows. Even on systems without limited resources, it's a benefit to be able to slim down the OS as much as possible and provide those resources to your application.

For those of us who install security updates automatically, this was patched within hours of being discovered, and each further patch has been applied within hours, as well. On a Windows system set to install updates automatically, bugs *still* go unpatched for months after being reported.

I'm saying this not as a Linux proponent, but as someone who uses all 3 major systems on a daily basis, for whom Linux isn't even a primary system.

Well, to be fair, Apple targets an audience with plenty of cash. Who goes on 2 month wilderness hikes? Perhaps a better question to illustrate my point: who can afford to go on 2 month wilderness hikes?

People with plenty of cash. Cash they could use to buy Apple devices.

Having an SD slot wouldn't stop someone from using the iPhone without an SD card. they could still sell the devices to the same market they currently sell them to, and as a shareholder I would certainly hope they would; but, also as a shareholder, I recognize the market they're missing. My example was extreme, so as to be clear, but there are hundreds of other, more common, scenarios in which an SD slot might be useful.

Hell, putting on the shareholder hat again, I'd be happy if they just made it an option on the 128GB model. Really, that would be ideal, as it would stop people from buying the 16GB model and slapping a 128GB SD card in it, while opening up a whole market that Apple is not tapping.

And it still took 20 years. That argument is bunk, just like the argument that it's automatically more secure because it's open. It *can be* more secure, but people actually have to audit it.

Let's play out a hypothetical, here. Let's say this exact bug exists within Powershell. When will it be discovered and patched?

Can you look for it? Nope. If Microsoft looking for it? Probably not, they're busy fixing *reported* bugs and writing *new* code. When will it be found? 20 years sounds optimistic.

Shellshock has nothing to do with Linux, either. Bash predates Linux by 2 years.

Well, let's see here... Heartbleed was a bug in OpenSSL, use in a lot of software that has nothing at all to do with Linux, and Shellshock is a bug in the Bash shell, which predates Linux by 2 years and is used on a lot of systems that have nothing at all to do with Linux. Neither bug was a Linux bug, though both affected Linux systems; both also had the ability to affect Windows systems running any number of applications that rely on OpenSSL (if you open your eyes, you might be amazed how many and how common) or Bash (fewer, but still not completely unheard of; there are a number of POSIX layers for Windows, and all of them use Bash by default as far as I'm aware).

The last time I posted these facts, I was modded flamebait, and I'm sure it'll happen again. Plenty of karma to burn, though, so, whatever.

So Blaster never happened?

I post factual information and get modded flamebait? Really? Bash is a shell and openSSL is a library, Linux uses both, but neither are a part of Linux; in fact, both are used in a *lot* of other products. That makes Heartbleed and ShellShock both not linux bugs.