URGENT! Shellshock Fix DOES NOT Fix The Bug On CentOS 5.4

Home » CentOS » URGENT! Shellshock Fix DOES NOT Fix The Bug On CentOS 5.4
CentOS 36 Comments

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

36 thoughts on - URGENT! Shellshock Fix DOES NOT Fix The Bug On CentOS 5.4

  • Never mind; false alarm. Apparently, we both had a previous ‘echo’ file sitting around from before.

    Best,

    Jessica

  • Jessica Blank wrote:

    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

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

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

  • 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

  • EL5 was never vulnerable to heartbleed to begin with, that said, your point is still valid as to other vulnerabilities.

    Peter

  • Not me. I’m on 5.10 and 6.5.

    The lady who enquired was happily using C 5.4


    Regards,

    Paul. England, EU.

  • Two typos:

    Para 5: $relesever s/b $releasever

    Para 9: componet s/b component (3x)

    Outside of the typos, it looks great to me!

  • 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

  • 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 :

    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?

  • 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

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

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

  • Sure, right after the last bug is found and fixed. Meanwhile we balance the risk of change against the risk of not changing.

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

  • William Woods writes:

    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.

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

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

  • 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?