This question already has an answer here:

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...

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...

"US-CERT recommends users and administrators review TA14-268A, Vulnerability Note VU#252743 and the Redhat Security Blog (link is external) for additional details and to refer to their respective Linux or Unix-based OS vendor(s) for an appropriate patch."

The question...

Should bash shells be replaced with these new patched versions?

RESOURCES


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.

marked as duplicate by bmike Sep 27 '14 at 4:21

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    Yes if you are running a server & feel that you are at risk. No if you are running Mac OS X as a client. And this is well covered on this site. Long story short: If you have no idea how to compile from source or deal with deep system components, you yourself will be the biggest risk due to the bash glitch. apple.stackexchange.com/questions/146893/… – JakeGould Sep 27 '14 at 2:03
  • I just reread your post. So you are basically stating that nobody should trust any update so no patches should be applied & that is that? – JakeGould Sep 27 '14 at 2:36
  • @JakeGould Sorry, forgot to reply. Please see last night's edits. – DocSalvager Sep 27 '14 at 17:39
up vote 2 down vote accepted

Yes, you should. Even in the very worst case, you're trading a known-exploitable version of a program for one that is theoretically exploitable only by whoever crafted a potential back door.

Tons of people know about the current problem and can use it against you right now, but presumably few people know about this hypothetical back door that may not even exist.

The decision seems like an easy one to me...at least if you're referring to the official patch released by the vendor of your OS. As for third-party patches, it comes down to a question of trust.

Personally, I will be patching, but I will be waiting for Apple, or at the very least for a trusted repository (Homebrew etc) to release a 3.2-series version of bash with the fix.

  • 1
    If you are running Mac OS X client the chances of this affecting you are pretty much zilch. More details here. apple.stackexchange.com/questions/146893/… – JakeGould Sep 27 '14 at 2:04
  • Even if the chances are small, you still generally want to patch security vulnerabilities. The other post, for example, focuses on direct exploitation from external systems. But what about privilege escalation? Are you absolutely positive that there are no setuid executables on your system that execute anything through bash in a way that would allow their environment variables to be influenced maliciously? – Scott Dudley Sep 27 '14 at 2:19
  • 1
    @TraneFrancks The only thing valid about the original question here specifically is that this potential “exploit” has been around for 22 years. Can you point to an instance where something like this compromised security? If I turn on web sharing on my desktop, that in & of itself won’t be vulnerable. Most modern Apache installs do not use CGI scripting. And that is the weakness. So simply enabling web sharing won’t make you a target. I stand by my statement that this is all panic with little tangible reality to back it up. – JakeGould Sep 27 '14 at 2:29
  • 1
    @TraneFrancks The best, sane, rational & succinct explanation of the impact of this flaw can be found here. And if you know anything about how web servers work—and how the Apache risk is really non-existent in modern Linux servers—then this is all a massive non-issue. And this is from RedHat! The folks who discovered it. All of my Linux servers are patched. My Mac servers don’t do anything to trigger bash on any level. And my Mac clients are just clients. I feel fine. – JakeGould Sep 27 '14 at 4:41
  • 1
    "and how the Apache risk is really non-existent in modern Linux servers" You obviously do not run a cPanel shared server on which 'CGI Center' is an expected feature by Web 1.0-oriented users. (I run a hosting company.) My CentOS servers are patched and not vulnerable. Honestly, I don't know why you think I don't feel fine. I feel wonderful. As for RH's non-issue: "Because of the pervasive use of the Bash shell, this issue is quite serious and should be treated as such." From here: access.redhat.com/articles/1200223 – Trane Francks Sep 27 '14 at 5:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.