Critical Update For Bash Released Today.
You should ‘yum update’ as soon as possible to resolve this issue.
Here’s why you should care:
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
Links to the CentOS updates:
CentOS-5:
http://lists.CentOS.org/pipermail/CentOS-announce/2014-September/020582.html
CentOS-6:
http://lists.CentOS.org/pipermail/CentOS-announce/2014-September/020585.html
CentOS-7:
http://lists.CentOS.org/pipermail/CentOS-announce/2014-September/020583.html
20 thoughts on - Critical Update For Bash Released Today.
For informational purposes:
https://access.redhat.com/articles/1200223
Thanks for the heads up.
good morning,
I installed the update on C5 and C6 machines, but I do not see any difference in the output of “bash –version”. Is that the expected behaviour?
C5 returns
—8<-
As a by heads up that advisory has been updated since the updated packages were released.
The fix in the previous packages is incomplete and there is a new cve being tracked as a result:
https://access.redhat.com/security/cve/CVE-2014-7169
That is not the way to check if you have the update installed. That is the major upstream bash version on which the Red Hat version is based
… this will likely never change throughout the lifetime of each individual man branch of CentOS .. that is, CentOS-5 will likely always say 3.2.25(1)-release, CentOS-6 will likely always say 4.1.2(1)-release, etc.
What you need to do to check the version is this:
rpm -q bash
the result should be (if you have the update):
for c5: bash-3.2-33.el5.1
for c6: bash-4.1.2-15.el6_5.1
for c7: bash-4.2.45-5.el7_0.2
Note: Some people may have ARCH enabled in their RPM commands, so a
.i386, .i686, .x86_64 might be on the end of the above output, so for c7, it might say: bash-4.2.45-5.el7_0.2.x86_64
Thanks, Johnny Hughes
If I understood correctly, the current fix is incomplete and another fix is planned?
Also, in the advisory, RH says that after the update, servers need to be rebooted… Really?
Aside from cgi/php, just closing all shells isn’t enough?
Thx, JD
John Doe wrote:
Yes. More info here – https://access.redhat.com/security/cve/CVE-2014-7169
No. From https://access.redhat.com/articles/1200223
—————–
FYI: Update: 2014-09-25 03:10 UTC
This article has been updated today 9/25/14 – saying the original patch is not complete.
FYI: Update: 2014-09-25 03:10 UTC
This article has been updated today 9/25/14 – saying the original patch is not complete.
Take the case of an Apache Bash CGI. This will have been loaded when Apache started, so Apache will have to be restarted to get the new one. There may be other similar cases. So the best thing is to reboot.
Cheers,
Cliff
I didn’t notice you had mentioned CGI. CGI (and PHP) is only one case where a copy of bash is loaded. There are many other possibilities, eg wrapper bash scripts, bash shell called from programs. I don’t know whether or not there are any such cases on my machines, or if the exploit can be executed through them, so I’d say that the best way to be sure is to reboot.
Cheers,
Cliff
Based on my (admittedly limited) testing I do not believe this is the case. Apache exec()’s the interpreter on each request; it doesn’t save the interpreter into its memory space, so each subsequent call should re-run the interpreter. That’s one of the big reasons mod_perl and their ilk are popular: they do put the interpreter into httpd’s memory, so the interpreter doesn’t have to be called on each invocation.
I don’t currently have a vulnerable interpreter available on a web server, but on the servers where I have an updated bash, the
“vulnerable” message that’s produced by the example code doesn’t show up in a bash CGI on a web server I haven’t restarted.
# example code env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
–keith
Apache
This is false and a major misunderstanding of the vulnerability.
1) the vulnerability is just during initialisation of bash. Once it is running it is beyond the vulnerable stage and needs no restarting
2) in a CGI of #!/bin/bash or for a system call with any other language for CGI bash gets executed on demand… It does not do what you say…
These are now released as well:
CentOS7:
http://lists.CentOS.org/pipermail/CentOS-announce/2014-September/020592.html
CentOS6:
http://lists.CentOS.org/pipermail/CentOS-announce/2014-September/020593.html
CentOS5:
http://lists.CentOS.org/pipermail/CentOS-announce/2014-September/020594.html
*NOTE*: CentOS-4 has been past End Of Life for a long time (February
2012), and this bash issue is just one of many Critical ones that mean you should not be running CentOS-4 in production where it in any way touches the Internet:
http://lists.CentOS.org/pipermail/CentOS-announce/2012-February/018462.html
If you absolutely must run an EL4 workload, please do not do it on CentOS-4 and instead pay for and upgrade to RHEL-4 ELS as described in the above link from February 2012. CentOS-4 is unsafe .. don’t use it
.. don’t do it .. please.
It is listed how one can check whether his system is vulnerable to shellshock or not & how to verify after the upgrade of bash rpm.
https://garage.godaddy.com/webpro/security/shellshock-vulnerability-need-know/
Better one ->
https://support.godaddy.com/help/article/12120/patching-bash-on-your-server-shellshock-patch
CentOS4 is perfectly safe to use :).
…… If it’s in a Virtual Machine with no network access :).
Kind Regards, Jake Shipton (JakeMS)
GPG Key: 0xE3C31D8F
GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F
Jake Shipton wrote:
If you _really_ want to update bash on EL4, Oracle have updated (S)RPMS
available – see:
https://oss.oracle.com/el4/SRPMS-updates/bash-3.0-27.0.2.el4.src.rpm
http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/bash-3.0-27.0.2.el4.i386.rpm
http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/x86_64/getPackage/bash-3.0-27.0.2.el4.x86_64.rpm
James Pearson
Or, use the source, Luke. There are official patches for 3.x and 4.x.
The patched code is so old that even 4.2 patch 48 applies cleanly(*) to bash-2.05b, which is RHEL3 territory.
http://ftp.gnu.org/gnu/bash/
* minus the patchlevel.h bit
You are 100% correct, sir. Sorry about the noise……
Cheers,
Cliff