OpenSSL Update – Not A Security Update???

Home » CentOS » OpenSSL Update – Not A Security Update???
CentOS 20 Comments

This command output is odd:

yum update –security
… No packages needed for security; 118 packages available

However, this command says there’s an OpenSSL update:

yum update openssl

—> Package openssl-libs.x86_64 1:1.0.1e-51.el7_2.2 will be updated
—> Package openssl-libs.x86_64 1:1.0.1e-51.el7_2.4 will be an update

Why does yum not consider this CESA a security update?

Perplexed, ak.

20 thoughts on - OpenSSL Update – Not A Security Update???

  • Cherry-picking updates is not supported by CentOS, this is because each package is built on a system with all previous updates applied and as such each update that you install should have all previous updates applied or there can be problems.

    As such CentOS does not support the –security option for yum, nor does it support the yum-security plugin. You are expected to update your entire system, not to do so will leave you with an unsupported system. Also there will be other packages as well that have security issues that need updating.

    Peter

  • –6AmTc4r5SXr2JbBMKTVV7rMoc0t95Et7W
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    RHEL does not support only security updates either .. they do have things like AUS / EAS .. but those things require all updates to be installed, not just all security updates.

    If you look at this update:

    https://access.redhat.com/errata/RHSA-2016:0303

    Look in the *Solution* section:

    “Before applying this update, make sure all previously released errata relevant to your system have been applied.”

    That does not say all security errata .. it says all errata. The same thing is on every Red Hat errata page. They expect that you are running whatever is an updated system. If you are running AUS or EUS, they still expect you to do all updates for that repo, not just security updates.

    BUt the security plugins do not work for CentOS and they never have, Peter is correct, you need to run yum update or call out the specific packages you want updated.

    You can look at the announce list to figure out which ones are SA or BA
    or EA .. but you want all of them, as they go together.

    –6AmTc4r5SXr2JbBMKTVV7rMoc0t95Et7W

  • –coWsHEQc489c3dL74dDuSxWpVIUdB3qWF
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    Also, just installing the update is not enough, you also need to make sure SSLv2 is disabled on the appropriate services:

    http://red.ht/1pngpQ2

    –coWsHEQc489c3dL74dDuSxWpVIUdB3qWF

  • I totally understand the necessity of a full system update. However, this begs the question “Why code an option into yum that is of no use?” Was there a time when this option was functional? If yes, what caused its removal? Was it a system compromise at some big corporation and someone got sued/fired? What?
    Don’t spare any gory details either!

    ak.

  • Specifically it requires errata data within the repo metadata.

    It exists in yum since CentOS is a RHEL rebuild and upstream provides that errata data for RHEL users.

    If you set up something like Spacewalk then you can use something like CEFS
    to import that errata data to make –security work for CentOS systems.

    https://cefs.steve-meier.de/

    Potentially you could use a combination of his work, a bit of scripting and createrepo to provide your own errata data.

    *That all being said* apply all errata still applies whenever issues arise
    ;)

  • yum does not need to be restricted to vendor repositories.

    You can add package repositories maintained by anyone, and some of them may choose to distinguish between security and non-security updates, so it is appropriate for yum as packaged in CentOS to retain that feature even if the CentOS repositories themselves do not make use of it.

    Personally I think it is a dumb option and is in contrast to KISS.

    KISS says keep your system up to date. RHEL/CentOS works really hard to prevent updates from breaking a system. That’s why many of us use it.

    So it doesn’t make sense to not update when an update is available, making security specific updates kind of worthless.

  • –nLN5NFNFasE8LricjfNSijFOCXTvEtlCS
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    It would require 2 things that we currently don’t do.

    1. Host all the RPMs every built in one place that every update can hit.

    2. An errata.xml file that contains information that is NOT open source and not allowed to be gathered by CentOS. (Although James Hogarth provided a link to one elsewhere in this thread)

    First for #1:

    We utilize several hundred servers and free bandwidth that they provide that are donated to the CentOS Project to distribute updates. This
    ‘donated network’ makes up the DNS names mirror.CentOS.org, msync.CentOS.org, and cloud.CentOS.org, etc. We use this network to distribute CentOS Linux to more than 630 servers (external mirrors) in
    85 countries all over the world.

    We could not provide CentOS for free for the last 13 years if we did not have both the hundreds of donated machines that make up mirror.CentOS.org (and msync.CentOS.org) OR those external mirrors.

    The vast majority of our donated mirror network servers do not have room to host all the RPMs from all active CentOS versions in one place and to distribute them to the vast external server network.

    We can’t afford to replace the hundreds of donated (free) servers with ones that CAN host that amount of data AND also pay for enough bandwidth to distribute it to the external mirrors. Even if we could, not all the current 635 mirrors would be able to take all that data.

    This is one of many reasons why there is a subscription price for RHEL.

    Even if we DID all of that. Other than returning a cou0ple of updates with the yum security plugin command, you STILL need to run ‘yum update’
    to get all the updates as JUST doing the security ones is not supported
    / does not necessarily fix the security issues.

    Then there is #2:

    The information that goes INTO the XML file we would need to generate does not come from the source code from Red Hat Enterprise Linux that we use to build CentOS Linux. It would only from screen scraping places like:

    https://rhn.redhat.com/errata/rhel-server-7-errata.html

    BUT, if you go to the ‘terms of use’ for Red Hat portals .. here:

    https://access.redhat.com/help/terms/

    You will see the definition of “Red Hat Content”. While we CAN
    distribute the software we build (it is open source) .. we *CAN NOT*
    scrape and/or Distribute content that is *NOT* open source but us copyrighted intellectual property.

    To the best of our knowledge, the information needed to make up all the information needed to create the Errata XML file requires to make the yum security plugin work is not available in a complete open source way where we would be able to be distributed.

    That is *WHY* the CentOS team does not copy and distribute any content into our announcements, but only links to open content in our announcements.

    So, we can not distribute the information that is required in the XML
    file that would make the yum security plugin work .. *BUT* even if we could, you *STILL* need to run ‘yum update’ to get all the updates as JUST doing the security ones is not supported / does not necessarily fix the security issues.

    Hopefully this makes sense.

    You can instead just look at this:

    https://lists.CentOS.org/pipermail/CentOS-announce/

    (or subscribe to the CentOS announce mailing list to get emails)

    Both of those places will tell you when there is a security update.

    OR, you can subscribe to RHEL and use the information in the yum security plugin.

    –nLN5NFNFasE8LricjfNSijFOCXTvEtlCS

  • Thanks for not sparing the gory details (and Alice and James) – much appreciated!

    I normally test my updates on non-critical systems before deploying to production. However, in this instance, I had been away from the office and wanted to quickly patch the openssl vulnerability before other non
    -critical/security related.

    In the end, I bit the bullet and just upgraded everything and no harm done.

    ak.

  • We are talking here CentOS and RHEL Linux. yum is an abbreviation of:
    “Yellowdog Update Manager”. It was originally created by YellowDog Linux project for their Linux distribution. I don’t know is they (YellowDog)
    actually using this particular feature or not, but RedHat (and hence CentOS) use features of yum they think fitting in their model. Incidentally, sometimes even when the project uses his own creature itself, they may end up abandoning some of the features that were originally coded in. Everyone who ever architectured some project himself, know that that often happens.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • One more voice on this: we actually run the yum security plugin, several times a week, and it does report things… and almost all our systems are CentOS.

    When I see something in there, just as when I see an announcement where there are updates marked important, and esp. critical, we roll them out, by themselves if possible, within days, as opposed to waiting until the maintenance window, which could be 3.5 weeks away.

    We only do the full updates during the maintenance window (or via negotiation with a workstation owner….)

    mark

  • Once upon a time, Valeri Galtsev said:

    Actually, yum is Yellowdog Updater, Modified. Seth Vidal (RIP) and others at Duke rewrote YUP (the Yellowdog UPdater) to handle Red Hat Linux.

  • Thanks, Chris! My memory ain’t that good anymore…

    valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • I understand that some people might be trying to cherry-pick their updates and the assertion that doing so is not supported. But that is not the only way in which –security can be used and it is a bit boring to continually see whining about the assumptive use.

    For me it is about scheduling — it would answer the question: Does this system need updating immediately, vs scheduled for / deferred until a convenient time.

    I wish –security was functional and I do not accept that because it can be abused that it should therefore never be. That CentOS as yet has no way to make it functional is sad, and I hope that the lack is not due to the assumed use resulting in it being ignored.

    /mark

  • –8FKGiWpDvHvr5k9uPwsxETRRpORtRnfCj Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    That is not the reason, I have posted the reason several times .. including in this thread.

    We do not have enough space on donated mirrors and the data required for the xml file is not redistributable.

    It is not being ignored, it was designed to be used within rhn and since we give CentOS away for free, we can’t buy the machines or bandwidth we need to include all rpms in all trees. Even if we could do that, we can’t steal information and redistribute it if it is not licensed for such distribution.

    –8FKGiWpDvHvr5k9uPwsxETRRpORtRnfCj

  • Surely the data could be tailored to provide only that which applies to the current set of RPMs. Do we know that yum will fail if RPMs are cited in the file but which are not available for install?

    That does sound like it is being ignored, because you know you can’t do it.

    As things stand.

    (I think you should put all this in an/the FAQ then point people to it, instead of sending large swaths of the same words yet again, which must surely be frustrating.)

    But the project could lobby Red Hat for access to the file, whether for just CentOS (RH has done things just for CentOS before) or for the wider community of rebuilders. I can’t know if this has been attempted, but it has not been mentioned as having been asked.

    Can I help lobby for such access? I bet that would only be possible after CentOS has started such a petition, since non-RHEL users cannot submit feature requests. But the CentOS project isn’t quite in the same boat as its users, so you might be able to open such a ticket and if it were public others could jump in with their support. Or would a SIG be the right avenue?

    Would Red Hat pay any attention to 3rd party lobbying sites? At least I
    think I remember such existing, though I cannot at the moment recall any names.

    /mark

  • –xjF3AqxuvVKjEr0fuDd0suprtI7aPj3hJ
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    Whose current set .. your’s or the guy that hasn’t done an update since
    2007?

    Te problem is, if we say we support the security plugin, then it has to be able to update ANY configuration and all security updates.

    Let’s say that you are on 6.4 right now, there is a security update in
    6.5 and 6.6, and there is a bugfix update in 6.7 (current version), you run the security plugin and it says .. no security updates (because the
    6.7 update is only a bugfix).

    You are instead behind and have a security problem .. no, you have to have all or it doesn’t work, and it then causes people to think they are OKwhen they are not.

    One of the things RHEL does that CentOS doesn’t do (and has never done)
    is verify security issues, verify fixes correct those issues and provide assurance that they are fixed. They is why RHEL is a paid product and CentOS is free.

    –xjF3AqxuvVKjEr0fuDd0suprtI7aPj3hJ

  • Hey all,

    Sorry to jump in here but out of curiosity, has the patch actually been back ported to earlier versions of OpenSSL regarding the recent DROWN attack? I’ve checked the RPM change log and nothing’s been mentioned relating to CVE-2016-0800 (I think that was the CVE number). Or is this thread not relating to that vulnerability?

    Kind regards

    James Washington

  • Drown depends upon SSLv2

    I’m not sure if this removed SSLv2 or not but I am not personally aware of any public services that enabled SSLv2 by default in CentOS 7 anyway, so unless you have a service supporting SSLv2 you are not vulnerable to DROWN.

    Reality is, you should not have either SSLv2 or SSLv3 enabled on any service and disabling was best practice long before DROWN.

  • –xST773KV2eRcKItGU2U4RHQAOHSNg3U70
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    Yes, this update addresses Drown .. but installing the update alone is not enough, you also have to turn off SSLv2

    You can see how to do that for many different services here:

    https://access.redhat.com/articles/1462183

    And lots of info here:

    https://access.redhat.com/security/vulnerabilities/drown

    –xST773KV2eRcKItGU2U4RHQAOHSNg3U70