Bash Code Injection Vulnerability CVE-2014-6271 : workarounds other than patching

Referring to :
"The Bash Code Injection Vulnerability CVE-2014-6271 could allow for arbitrary code execution, allowing an attacker to bypass imposed environment restrictions"


Q1:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6271
The bugzilla link above indicates quite a number of issues do not affect RHEL 5.x & 6.x
other than a few listed on the top of the page.  Are all the issues related to CVE-2014-6271
or only the first one listed on the very top?

Q2:
If we don't use Bash, does this mean we are not vulnerable?  Thought this will be
quick workaround.

Q3:
https://access.redhat.com/articles/1200223
Does the patches in the above link change the version/sub-version of the RHEL?
I'm concerned the patches may break applications but judging from what the
patches do (extracted below from the above link), looks like only a handful of
products are affected, so can I safely assume that as long as these packages
are not used in my environment, I'm quite safe?

Package      Description
httpd      CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.
Secure Shell (SSH)      It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.
dhclient      The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.
CUPS      It is believed that CUPS is affected by this issue. Various user supplied values are stored in environment variables when cups filters are executed.
sudo      Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.
Firefox      We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.
Postfix      The Postfix server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.
sunhuxAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Seth SimmonsSr. Systems AdministratorCommented:
Are all the issues related to CVE-2014-6271 or only the first one listed on the very top?

not sure if i understand the question
if you are referring to all the comments posted, as stated at the bottom (comments from today) this is bash-only and doesn't apply to other shells

If we don't use Bash, does this mean we are not vulnerable?

it lowers the chance of being exploited but does not eliminate it
some applications or installer scripts could still use it

Does the patches in the above link change the version/sub-version of the RHEL?

no, only the version of bash
going forward, newer minor and major revisions of RHEL will include this patch but the patch itself does not constitute a new RHEL version.  usually with a newer RHEL version there are updates to the kernel, numerous packages and often feature enhancements.  this is just a patch
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jan SpringerCommented:
CentOS is essentiall RHEL.  Try a "yum check-update" and see if your distribution has an update available.  

CentOS and Ubuntu did this morning.
0
Jan SpringerCommented:
And you also have the option of downloading bash from source, applying the patches and installing it.

You can test it by renaming the newly compiled "bash" binary to something like "bash-alt" and testing it with a non-priv account.
0
Top Threats of Q1 & How to Defend Against Them

WEBINAR: Join WatchGuard CTO and our Threat Research Team on Aug. 2nd to hear the findings from our Q1 Internet Security Report! Learn more about the top threats detected in the first quarter and how you can defend your business against them!

sunhuxAuthor Commented:
I can't do yum as our VMs are not connected to Internet.

Perhaps one way to find out is to rename the bash binary in our
RHEL & SuSE & see if anything breaks: we can always reverse
back quickly by renaming it back.  Does this make sense?

Is ESXi (for vSphere V5.0) affected?  I read in one site that VMware is still
assessing
0
Jan SpringerCommented:
Your other option is to change the shell used by CGIs to "sh" (accounting for any syntax changes needed).

But yes, you are correct.
0
gheistCommented:
A1: vulnerability is "remote" when you have bash script (one starting with #!/bin/bash in cgi directories
A2: see the first question - you can still keep BASH as your shell.
A3: no, redhat version is in package redhat-release, you can downgrade that to whichever version you want to see. It is a one-file package.

If you have ELS/EUS support from redhat then make sure you re-subscribe your systems to hefty ELS/EUS channels via RHN register. For poor people and chary organisations it is either yum upgrade --security, or quick conversion to CentOS or oracle linux stains.
0
Jan SpringerCommented:
I wouldn't refer to the non-RHEL customers "poor" or "charitable".

I've been down the licensed support path with many operating systems to include RHEL.

It was definitely not worth the money.
0
gheistCommented:
I just try to imagine the long leap RH customer took to report this bug...
I was more about customers who live with standard package as opposed to 4x more expensive EUS (like onec claiming running RHEL 4.3 forever)
0
patronCommented:
it will impact ESX and  and vMa only,not applicable for ESXi.
0
gheistCommented:
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
OS Security

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.