On 26 Sep 2014 05:46, Cliff Pratt enkiduonthe...@gmail.com wrote:
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.
This is false and a
On 09/25/2014 01:49 AM, James Hogarth wrote:
On 24 Sep 2014 17:12, Johnny Hughes joh...@centos.org wrote:
For informational purposes:
https://access.redhat.com/articles/1200223
As a by heads up that advisory has been updated since the updated packages
were released.
The fix in the
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/
On Fri, Sep 26, 2014 at 4:24 PM, Johnny Hughes joh...@centos.org wrote:
On
Better one -
https://support.godaddy.com/help/article/12120/patching-bash-on-your-server-shellshock-patch
On Fri, Sep 26, 2014 at 4:33 PM, Ankush Grover ankushcen...@gmail.com
wrote:
It is listed how one can check whether his system is vulnerable to
shellshock or not how to verify after the
On 26/09/14 11:54, Johnny Hughes wrote:
On 09/25/2014 01:49 AM, James Hogarth wrote:
snip
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
Jake Shipton wrote:
On 26/09/14 11:54, Johnny Hughes wrote:
On 09/25/2014 01:49 AM, James Hogarth wrote:
snip
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
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.
Or, use the source, Luke. There are official patches for
On Fri, Sep 26, 2014 at 6:28 PM, James Hogarth james.hoga...@gmail.com
wrote:
On 26 Sep 2014 05:46, Cliff Pratt enkiduonthe...@gmail.com wrote:
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.
good morning,
You should 'yum update' as soon as possible to resolve this issue.
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---
GNU bash, version 3.2.25(1)-release
On 09/25/2014 01:07 AM, Michael Schumacher wrote:
good morning,
You should 'yum update' as soon as possible to resolve this issue.
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
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:
If I understood correctly, the current fix is incomplete and another fix is
planned?
Yes. More info here - https://access.redhat.com/security/cve/CVE-2014-7169
Also, in the advisory, RH says that after the update, servers need to be
rebooted... Really?
No. From
On 09/24/2014 12:11 PM, Johnny Hughes wrote:
On 09/24/2014 10:26 AM, Jim Perrin wrote:
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/
On 09/24/2014 12:11 PM, Johnny Hughes wrote:
On 09/24/2014 10:26 AM, Jim Perrin wrote:
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/
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
On Fri, Sep 26, 2014 at 2:39 AM, John Doe jd...@yahoo.com wrote:
If I
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
On 2014-09-26, Cliff Pratt enkiduonthe...@gmail.com wrote:
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.
Based on my (admittedly limited) testing I do not believe this is the
case. Apache exec()'s
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:
On 09/24/2014 10:26 AM, Jim Perrin wrote:
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:
On Wed, Sep 24, 2014 at 11:11 AM, Johnny Hughes joh...@centos.org wrote:
On 09/24/2014 10:26 AM, Jim Perrin wrote:
You should 'yum update' as soon as possible to resolve this issue.
Here's why you should care:
20 matches
Mail list logo