This question has generated a lot of downvoting on three SE sites so let me try to explain where it comes from.
The magnitude of the bash "shellshock" problem may turn out to be larger than anything since Y2K.
Having been part of a complete replacement of a large data center for Y2K, I'm alarmed at the panic that's been generated over shellshock (appropo name, btw). I'm concerned that rushing in quick fixes without extensive planning and testing is going to create far greater problems than the one we think we are facing.
For Y2K, we learned that the date code fixes were the easy part.
The massively more complex, error-prone, and unscheduled downtime-producing part was discovering and fixing/mitigating the failures in other software caused by the fixes. Some of these weren't discovered until the new systems had been in production for months. Despite a herculean effort, a few even resulted in organizational policy changes because they were too disruptive to fix.
I am not suggesting that security-patching is unadvisable.
However, in this case only, I have noticed a suspicious series of events culminating in not just another run-of-the-mill vulnerability, but one demanding massive updating of systems affecting virtually every person using a computer on the planet.
The vulnerability is real. But is the need for instant action?
It is this combination of factors that gives me pause...
A fact...
A timeline...
- Oct 2012 - "Apple is added to the NSA’s list of penetrated servers"
- Dec 2013 - Apple Says It Has Never Worked With NSA...
- Sep 19, 2014 - Likely that NSA has now demanded Apple's data and they are resisting
- Sep 24, 2014 - US-CERT is aware of a Bash vulnerability affecting Unix-based operating systems such as Linux and Mac OS X
Ramifications...
- The Bash shellshock "vulnerability" has been a "feature" of Bash for 22 years. You'd think in all that time, in all those high-security environments that run Unix or Linux, someone would have worried about misuse.
- Now, every installation of Bash in the world is about to be replaced.
- Though Bash is open-source, few people actually take the time to study the code of such large and complex programs.
- Bash is written in C, which supports embedded assembly-language code. Code that even fewer programmers have the skills to read.
- Bash is written in C, which easily supports treating any block of binary, such as something labeled as data or a small image, as code.
- Thus, a skilled programmer could hide "backdoor" code in plain sight, and it probably wouldn't be discovered unless it caused an error of some kind.
The claim...
The question...
Should bash shells be replaced with these new patched versions?
RESOURCES
- bash patching team discussion on insecure.org
- Apple: “The vast majority of OS X users are not at risk to recently reported bash vulnerabilities,"
- Red Security Blog: Bash specially-crafted environment variables code injection attack
Update 2017-09-28
After 3 years, someone actually found a sliver of usefulness in this and upvoted the question?
Well then, let me a mea culpa...
The above's focus on the circumstances surrounding Shellshock's announcement were a knee-jerk reaction on my part. A reaction I regret. While factual, the "conspiratorial" tone produced a backlash that obscured anything of value. I leave it intact only so that the many good comments make sense.
Enough new versions of most of the software involved have been released and well vetted by now that Shellshock may only still be of some concern to those running low-powered systems that must use older software. My alarm at the time was over the dangers of blindly removing 22 year old functionality from those systems with no analysis of the impact. Apparently, it turns out that the functionality was rarely, if ever, used.
