Good afternoon!
After applying the latest bash RPM listed at http://lists.centos.org/pipermail/centos-announce/2014-September/020594.html :
The fixed RPM (bash-3.2-33.el5_10.4.x86_64.rpm) DOES work just fine on CentOS 5.10. However, it DOES NOT work on CentOS 5.4. That is, bash runs fine, but IS STILL VULNERABLE TO SHELLSHOCK!
Scary screenie at: http://i.imgur.com/yR7sBjV.png
It looks like the released RPM somehow behaves DIFFERENTLY on 5.4 as opposed to 5.10.
This has been validated by one of my coworkers; it's apparently not just me.
Best,
Jessica
Never mind; false alarm. Apparently, we both had a previous 'echo' file sitting around from before.
Best,
Jessica
On Fri, 26 Sep 2014, Jessica Blank wrote:
Good afternoon!
After applying the latest bash RPM listed at http://lists.centos.org/pipermail/centos-announce/2014-September/020594.html :
The fixed RPM (bash-3.2-33.el5_10.4.x86_64.rpm) DOES work just fine on CentOS 5.10. However, it DOES NOT work on CentOS 5.4. That is, bash runs fine, but IS STILL VULNERABLE TO SHELLSHOCK!
Scary screenie at: http://i.imgur.com/yR7sBjV.png
It looks like the released RPM somehow behaves DIFFERENTLY on 5.4 as opposed to 5.10.
This has been validated by one of my coworkers; it's apparently not just me.
Best,
Jessica
Jessica Blank wrote:
Good afternoon!
After applying the latest bash RPM listed at http://lists.centos.org/pipermail/centos-announce/2014-September/020594.html : The fixed RPM (bash-3.2-33.el5_10.4.x86_64.rpm) DOES work just fine on CentOS 5.10. However, it DOES NOT work on CentOS 5.4. That is, bash runs fine, but IS STILL VULNERABLE TO SHELLSHOCK!
Scary screenie at: http://i.imgur.com/yR7sBjV.png
It looks like the released RPM somehow behaves DIFFERENTLY on 5.4 as opposed to 5.10.
This has been validated by one of my coworkers; it's apparently not just me.
Please note that the rpm is only for 5.10. You need to look around to see if there *is* an update for 5.4....
mark
On Fri, Sep 26, 2014 at 3:24 PM, m.roth@5-cent.us wrote:
Jessica Blank wrote:
Good afternoon!
After applying the latest bash RPM listed at http://lists.centos.org/pipermail/centos-announce/2014-September/020594.html : The fixed RPM (bash-3.2-33.el5_10.4.x86_64.rpm) DOES work just fine on CentOS 5.10. However, it DOES NOT work on CentOS 5.4. That is, bash runs fine, but IS STILL VULNERABLE TO SHELLSHOCK!
Scary screenie at: http://i.imgur.com/yR7sBjV.png
It looks like the released RPM somehow behaves DIFFERENTLY on 5.4 as opposed to 5.10.
This has been validated by one of my coworkers; it's apparently not just me.
Please note that the rpm is only for 5.10. You need to look around to see if there *is* an update for 5.4....
Not necessarily. The whole point of the way 'enterprise' OS versions keep their library APIs consistent means you can usually any package without breaking things - and that should apply to internal packages as well as your own. And system packages that need specific versions should say so in their rpm dependencies to bring them along if you try to update.
On Fri, 2014-09-26 at 15:02 -0500, Jessica Blank wrote:
Scary screenie at: http://i.imgur.com/yR7sBjV.png
Never mind the "scary screen" why are you deliberately using an insecure and out-of-date 5.4 version of Centos ?
Common sense says that if you are genuinely interested in security then you always update.
Regards,
Paul. England, EU.
Learning until I die or experience dementia.
2014-09-27 0:42 GMT+03:00 Always Learning centos@u62.u22.net:
On Fri, 2014-09-26 at 15:02 -0500, Jessica Blank wrote:
Scary screenie at: http://i.imgur.com/yR7sBjV.png
Never mind the "scary screen" why are you deliberately using an insecure and out-of-date 5.4 version of Centos ?
Common sense says that if you are genuinely interested in security then you always update.
uh. is this system even patched for heartbleed?
-- Eero
On Sat, Sep 27, 2014 at 01:29:44AM +0300, Eero Volotinen wrote:
2014-09-27 0:42 GMT+03:00 Always Learning centos@u62.u22.net:
Scary screenie at: http://i.imgur.com/yR7sBjV.png
Never mind the "scary screen" why are you deliberately using an insecure and out-of-date 5.4 version of Centos ?
Do we have a FAQ we can point people to that explains this? It's not obvious, and we need to educate anyone who shows up here not knowing the insecure nature of point releases older than tip.
-- greg
On 09/26/2014 06:23 PM, Greg Lindahl wrote:
On Sat, Sep 27, 2014 at 01:29:44AM +0300, Eero Volotinen wrote:
2014-09-27 0:42 GMT+03:00 Always Learning centos@u62.u22.net:
Scary screenie at: http://i.imgur.com/yR7sBjV.png
Never mind the "scary screen" why are you deliberately using an insecure and out-of-date 5.4 version of Centos ?
Do we have a FAQ we can point people to that explains this? It's not obvious, and we need to educate anyone who shows up here not knowing the insecure nature of point releases older than tip.
How is this:
2014-09-27 0:42 GMT+03:00 Always Learning centos@u62.u22.net:
Never mind the "scary screen" why are you deliberately using an insecure and out-of-date 5.4 version of Centos ?
On 09/26/2014 06:23 PM, Greg Lindahl wrote:
Do we have a FAQ we can point people to that explains this? It's not obvious, and we need to educate anyone who shows up here not knowing the insecure nature of point releases older than tip.
On Sat, 2014-09-27 at 08:28 -0500, Johnny Hughes wrote:
How is this:
Brilliant. Very well written. I hope it appeals to, inter alia, Centos 5.4 devotees :-)
5.4 ? really…. 5.4 ? you have a lot of other issues to worry about.
On Sep 27, 2014, at 8:28 AM, Johnny Hughes johnny@centos.org wrote:
On 09/26/2014 06:23 PM, Greg Lindahl wrote:
On Sat, Sep 27, 2014 at 01:29:44AM +0300, Eero Volotinen wrote:
2014-09-27 0:42 GMT+03:00 Always Learning centos@u62.u22.net:
Scary screenie at: http://i.imgur.com/yR7sBjV.png
Never mind the "scary screen" why are you deliberately using an insecure and out-of-date 5.4 version of Centos ?
Do we have a FAQ we can point people to that explains this? It's not obvious, and we need to educate anyone who shows up here not knowing the insecure nature of point releases older than tip.
How is this:
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, 2014-09-27 at 09:31 -0500, William Woods wrote:
5.4 ? really…. 5.4 ? you have a lot of other issues to worry about.
Not me. I'm on 5.10 and 6.5.
The lady who enquired was happily using C 5.4
My mistake then, apologies.
On Sep 27, 2014, at 9:36 AM, Always Learning centos@u62.u22.net wrote:
On Sat, 2014-09-27 at 09:31 -0500, William Woods wrote:
5.4 ? really…. 5.4 ? you have a lot of other issues to worry about.
Not me. I'm on 5.10 and 6.5.
The lady who enquired was happily using C 5.4
-- Regards,
Paul. England, EU.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
William Woods writes:
5.4 ? really???. 5.4 ? you have a lot of other issues to worry about.
Repeating it three times doesn't make an arrogant statement more true.
There are corporate environments that cannot upgrade for various reasons. Also, the history and performance of e.g autofs on RHEL/CentOS is truly awful. 5.4 does quite well in this regard, and later releases don't.
Obviously, there is no excuse for not upgrading Internet facing systems.
On 09/29/2014 04:15 AM, lhecking@users.sourceforge.net wrote:
William Woods writes:
5.4 ? really???. 5.4 ? you have a lot of other issues to worry about.
Repeating it three times doesn't make an arrogant statement more true.
There are corporate environments that cannot upgrade for various reasons. Also, the history and performance of e.g autofs on RHEL/CentOS is truly awful. 5.4 does quite well in this regard, and later releases don't.
...
I read the thread before replying, and didn't see anyone mention that, if one needs an open source stay-on-a-point-release setup, one should investigate Scientific Linux, which does do this. Yes, you can stay on 5.4 and get only the security updates. This is one of the differences between SL and CentOS. (now, they only build for releases where upstream releases sources; thus, if you're on EL4, no updates for you.....).
The latest shellshock update from SL, for SL 5.4 x86_64 (which would install on C5.4 unmodified, I would imagine), is: ftp://ftp.scientificlinux.org/linux/scientific/54/x86_64/updates/security/bash-3.2-33.el5_11.4.x86_64.rpm
For certain scientific applications, there are serious reasons to stay at a point release, and SL supplies to this niche.
If I were to need this specific niche here I would run SL at a point release without hesitation.
On Mon, Sep 29, 2014 at 8:36 AM, Lamar Owen lowen@pari.edu wrote:
I read the thread before replying, and didn't see anyone mention that, if one needs an open source stay-on-a-point-release setup, one should investigate Scientific Linux, which does do this. Yes, you can stay on 5.4 and get only the security updates. This is one of the differences between SL and CentOS. (now, they only build for releases where upstream releases sources; thus, if you're on EL4, no updates for you.....).
The latest shellshock update from SL, for SL 5.4 x86_64 (which would install on C5.4 unmodified, I would imagine), is: ftp://ftp.scientificlinux.org/linux/scientific/54/x86_64/updates/security/bash-3.2-33.el5_11.4.x86_64.rpm
For certain scientific applications, there are serious reasons to stay at a point release, and SL supplies to this niche.
If I were to need this specific niche here I would run SL at a point release without hesitation.
This is one of the reasons why I run SL on a computer that needs to stay at an earlier version because of certain in-house software. A little more detailed description about how security updates are provided in SL can be found near the bottom of this blog:
http://blog.toracat.org/2013/05/install-security-updates-in-rhel/
Akemi
Now that we just had another mailing list question about running old versions of CentOS, I see that my suggested FAQ addition wasn't added. Did I make my suggestion in the wrong place? What should I do next?
5.4 ? really…. 5.4 ? you have a lot of other issues to worry about.
On Sep 27, 2014, at 8:28 AM, Johnny Hughes johnny@centos.org wrote:
On 09/26/2014 06:23 PM, Greg Lindahl wrote:
On Sat, Sep 27, 2014 at 01:29:44AM +0300, Eero Volotinen wrote:
2014-09-27 0:42 GMT+03:00 Always Learning centos@u62.u22.net:
Scary screenie at: http://i.imgur.com/yR7sBjV.png
Never mind the "scary screen" why are you deliberately using an insecure and out-of-date 5.4 version of Centos ?
Do we have a FAQ we can point people to that explains this? It's not obvious, and we need to educate anyone who shows up here not knowing the insecure nature of point releases older than tip.
How is this:
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
5.4 ? REally 5.4….
You have lots of other issues to be concerned with.
On Sep 27, 2014, at 8:28 AM, Johnny Hughes johnny@centos.org wrote:
On 09/26/2014 06:23 PM, Greg Lindahl wrote:
On Sat, Sep 27, 2014 at 01:29:44AM +0300, Eero Volotinen wrote:
2014-09-27 0:42 GMT+03:00 Always Learning centos@u62.u22.net:
Scary screenie at: http://i.imgur.com/yR7sBjV.png
Never mind the "scary screen" why are you deliberately using an insecure and out-of-date 5.4 version of Centos ?
Do we have a FAQ we can point people to that explains this? It's not obvious, and we need to educate anyone who shows up here not knowing the insecure nature of point releases older than tip.
How is this:
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, 27 Sep 2014 08:28:48 -0500 Johnny Hughes wrote:
How is this:
Two typos:
Para 5: $relesever s/b $releasever
Para 9: componet s/b component (3x)
Outside of the typos, it looks great to me!
On Sat, Sep 27, 2014 at 11:10:54AM -0600, Frank Cox wrote:
On Sat, 27 Sep 2014 08:28:48 -0500 Johnny Hughes wrote:
How is this:
Two typos:
Para 5: $relesever s/b $releasever
Para 9: componet s/b component (3x)
Outside of the typos, it looks great to me!
one more typo:
You should NOT try to maintain yourself on a specifc minor version CentOS as all ^ of
On Sat, Sep 27, 2014 at 08:28:48AM -0500, Johnny Hughes wrote:
On 09/26/2014 06:23 PM, Greg Lindahl wrote:
Do we have a FAQ we can point people to that explains this? It's not obvious, and we need to educate anyone who shows up here not knowing the insecure nature of point releases older than tip.
How is this:
That's good, but I suspect that the question might not make it obvious that people need to read it. How about this additional Q/A?
Q. I want to run an old minor release of CentOS, for example staying with CentOS 5.4 when the latest version is 5.10. Is that smart?
A. No. CentOS only updates the most recent of each of the major versions. For example, for CentOS 5, if the most recent minor version is 5.10, then that is the only version that is receiving security updates. CentOS 5.4 is frozen and never gets any updates. That means that CentOS 5.4 is vulnerable to the "shellshock" problem.
If you really need to run an old minor version, you should consider paying for the upstream Enterprise Linux. They keep all the old minor versions up-to-date with regard to security fixes. CentOS does not.
-- greg
On 9/27/2014 2:53 PM, Greg Lindahl wrote:
A. No. CentOS only updates the most recent of each of the major versions. For example, for CentOS 5, if the most recent minor version is 5.10, then that is the only version that is receiving security updates. CentOS 5.4 is frozen and never gets any updates. That means that CentOS 5.4 is vulnerable to the "shellshock" problem.
or in another way of looking at it, when you apply all outstanding updates to 5.4, it becomes 5.10+
Am 27.09.2014 um 23:53 schrieb Greg Lindahl lindahl@pbm.com:
If you really need to run an old minor version, you should consider paying for the upstream Enterprise Linux. They keep all the old minor versions up-to-date with regard to security fixes. CentOS does not.
https://access.redhat.com/support/policy/updates/errata#Extended_Update_Supp...
-- LF
On Sun, Sep 28, 2014 at 02:12:27AM +0200, Leon Fauster wrote:
Am 27.09.2014 um 23:53 schrieb Greg Lindahl lindahl@pbm.com:
If you really need to run an old minor version, you should consider paying for the upstream Enterprise Linux. They keep all the old minor versions up-to-date with regard to security fixes. CentOS does not.
https://access.redhat.com/support/policy/updates/errata#Extended_Update_Supp...
Senator, we need a verb.
From reading the link, it appears that you want to clarify that it's
not "all the old minor versions", but I'm not sure that I understood what you meant, given that you posted a bare link with no explanation.
Am I right?
Am 28.09.2014 um 02:22 schrieb Greg Lindahl lindahl@pbm.com:
On Sun, Sep 28, 2014 at 02:12:27AM +0200, Leon Fauster wrote:
Am 27.09.2014 um 23:53 schrieb Greg Lindahl lindahl@pbm.com:
If you really need to run an old minor version, you should consider paying for the upstream Enterprise Linux. They keep all the old minor versions up-to-date with regard to security fixes. CentOS does not.
https://access.redhat.com/support/policy/updates/errata#Extended_Update_Supp...
From reading the link, it appears that you want to clarify that it's not "all the old minor versions", but I'm not sure that I understood what you meant, given that you posted a bare link with no explanation.
Am I right?
Sorry for my brief input but the intention was exactly what you extracted from the URI above and its valid only for the upstream. CentOS will stay always on the latest release as you also stated.
IMHO they are rare cases where some one are technically forced to stay on older releases. I do not argue that they didn't exist. We should not forget the context; stable ABI, API and mayor releases of the provided components, and not like e.g. Fedora with there "bleeding edge" approach (valid for there scenarios).
It would be great to get some feedback what such cases are, that let people stay on older releases?
-- Thanks LF
On Sun, Sep 28, 2014 at 01:32:38PM +0200, Leon Fauster wrote:
It would be great to get some feedback what such cases are, that let people stay on older releases?
Upstream can change the kernel module API quite violently in minor releases, which means that hardware products that have associated kernel modules often are a release behind.
Certification is another source of lag. It can take a while to certify that the test suite for a complicated product (like a commercial database) runs successfully on a new minor release. Some vendors skip half the minor releases (or more) to reduce cost.
A third source is companies with homegrown code deployed on CentOS servers and poor-quality test suites. They tend to be in the "omg never change anything unless forced at gunpoint!" camp. It's an unfortunate situation, and it can cost a lot of money and time to fix.
Not sure that this goes in the FAQ, though!
-- greg
On Sep 28, 2014, at 11:22, Greg Lindahl lindahl@pbm.com wrote:
Not sure that this goes in the FAQ, though!
No. If people have a good reason for doing it, they will generally know that reason. If the don't know one, they probably have no real need for staying at the earlier release.
On Sun, Sep 28, 2014 at 12:22 PM, Greg Lindahl lindahl@pbm.com wrote:
A third source is companies with homegrown code deployed on CentOS servers and poor-quality test suites. They tend to be in the "omg never change anything unless forced at gunpoint!" camp. It's an unfortunate situation, and it can cost a lot of money and time to fix.
Or even with decent test suites you recognize that you can't perfectly emulate a live internet-connected production environment. Or you've been burned by updates that did break things and the time it took to find a workaround. There's just no getting around complicated systems being complicated.
On Sun, Sep 28, 2014 at 6:32 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Sun, Sep 28, 2014 at 12:22 PM, Greg Lindahl lindahl@pbm.com wrote:
A third source is companies with homegrown code deployed on CentOS servers and poor-quality test suites. They tend to be in the "omg never change anything unless forced at gunpoint!" camp. It's an unfortunate situation, and it can cost a lot of money and time to fix.
Or even with decent test suites you recognize that you can't perfectly mulate a live internet-connected production environment. Or you've
been burned by updates that did break things and the time it took to
f>nd a workaround. There's just no getting around complicated systems being complicated.
Hence the need for immutable infrastructure.
vu
-- Les Mikesell lesmikesell@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sun, Sep 28, 2014 at 6:13 PM, Vojin Urosevic vu@linuxusers.com wrote:
On Sun, Sep 28, 2014 at 6:32 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Sun, Sep 28, 2014 at 12:22 PM, Greg Lindahl lindahl@pbm.com wrote:
A third source is companies with homegrown code deployed on CentOS servers and poor-quality test suites. They tend to be in the "omg never change anything unless forced at gunpoint!" camp. It's an unfortunate situation, and it can cost a lot of money and time to fix.
Or even with decent test suites you recognize that you can't perfectly mulate a live internet-connected production environment. Or you've
been burned by updates that did break things and the time it took to
f>nd a workaround. There's just no getting around complicated systems being complicated.
Hence the need for immutable infrastructure.
Sure, right after the last bug is found and fixed. Meanwhile we balance the risk of change against the risk of not changing.
Looks like the bash exploit tune may still be playing....
http://www.itnews.com.au/News/396256,further-flaws-render-shellshock-patch-i...
On 29 Sep 2014 05:37, "Frank Cox" theatre@melvilletheatre.com wrote:
Looks like the bash exploit tune may still be playing....
http://www.itnews.com.au/News/396256,further-flaws-render-shellshock-patch-i...
Well 7169 is already patched, 7186 isn't in the RH database so it would appear they don't consider that an issue and 7187 is not vulnerable in RHEL.
On 29 Sep 2014 07:37, "James Hogarth" james.hogarth@gmail.com wrote:
On 29 Sep 2014 05:37, "Frank Cox" theatre@melvilletheatre.com wrote:
Looks like the bash exploit tune may still be playing....
http://www.itnews.com.au/News/396256,further-flaws-render-shellshock-patch-i...
Well 7169 is already patched, 7186 isn't in the RH database so it would
appear they don't consider that an issue and 7187 is not vulnerable in RHEL.
Scratch that... I fail at the copy paste challenge...
https://access.redhat.com/security/cve/CVE-2014-7186
Looks like we may find one more bash patch at least yet then.
On 9/28/2014 11:39 PM, James Hogarth wrote:
https://access.redhat.com/security/cve/CVE-2014-7186
Looks like we may find one more bash patch at least yet then.
per https://rhn.redhat.com/errata/RHSA-2014-1306.htm the fix for 7187 and 7186 is already included in the updated fix that was released a couple days ago, bash-4.1.2-15.el6_5.2 etc.
On 09/29/2014 01:46 AM, John R Pierce wrote:
On 9/28/2014 11:39 PM, James Hogarth wrote:
https://access.redhat.com/security/cve/CVE-2014-7186
Looks like we may find one more bash patch at least yet then.
per https://rhn.redhat.com/errata/RHSA-2014-1306.htm the fix for 7187 and 7186 is already included in the updated fix that was released a couple days ago, bash-4.1.2-15.el6_5.2 etc.
That is correct, the latest released update patches all the known issues so far for all 3 Active versions of CentOS (CentOS-5, CentOS-6, CentOS-7) and was released within 21 Minutes after the announcement by RedHat of the RHEL releases.
So, for now, we are all caught up.
On 29 Sep 2014 07:47, "John R Pierce" pierce@hogranch.com wrote:
On 9/28/2014 11:39 PM, James Hogarth wrote:
https://access.redhat.com/security/cve/CVE-2014-7186
Looks like we may find one more bash patch at least yet then.
per https://rhn.redhat.com/errata/RHSA-2014-1306.htm the fix for 7187
and 7186 is already included in the updated fix that was released a couple days ago, bash-4.1.2-15.el6_5.2 etc.
Oh cheers John...
Somehow my eyes glazed right over the RHSA at the bottom of the CVE page...
I blame Monday morning.
-
Akemi Yagi -
Always Learning -
Devin Reade -
Eero Volotinen -
Frank Cox -
Fred Smith -
Greg Lindahl -
James Hogarth -
Jessica Blank -
John R Pierce -
Johnny Hughes -
Lamar Owen -
Leon Fauster -
Les Mikesell -
lhecking＠users.sourceforge.net -
m.roth＠5-cent.us -
Peter -
Vojin Urosevic -
William Woods