Why is my Red Hat Enterprise Linux 7 OpenSSL version 1.0.1e, since upstream already has 1.1 or 1.0.2?
Why is Red Hat shipping PHP 6, when upstream is already in version 7?
Red Hat Enterprise Linux 6 is still in supported status! But Red Hat Enterprise Linux 6's apache is still version 2.2!
Or even: We ran our vulnerability scanner and it still reports that our all-updates-installed server has vulnerable packages!
Don't lose your mind! We can shed some light on your package version questions.
Sowing the seeds of the future
Our story starts at Fedora Project. Think of Fedora as a test tube where we add the latest and newest version of all packages that comprise an operating system distro. And new technologies, too! We take what's new, trending and desirable for a further Red Hat Enterprise Linux release and put it into testing via Fedora. Some changes are kept in the next version, others are dropped: all the Fedora experience and community feedback are taken into account to craft the next enterprise product evolution.
The upstream project sows the seeds of our next enterprise version!
The Birth of Something New
After lots of use, test and bugfixes by the Fedora Community, we elect a given Fedora release and freeze every package version (attention here!) that was part of the selected Fedora release.
Hey, you won't want a green piece of code into your mission-critical environment, right?
That's also true for every community project that Red Hat tracks for our enterprise products. As a curiosity, Red Hat Enterprise Linux 5 was based on Fedora Core 6, Red Hat Enterprise Linux 6 was based on both Fedora 12 and 13 and Red Hat Enterprise Linux 7 took Fedora 19 and 20 as the source of inspiration. For more information, check this link.
Something new and cool shows up!
What if something really cool shows up upstream and you really really need that imported into Red Hat Enterprise Linux? That happens more frequently that you might imagine. You can also drive it: You can file a support case referencing an upstream feature along with its description and commits and request inclusion in our products. Notice that as the product evolves into its production phase, feature inclusions become more and more strict. We import new functionalities, driver updates, hardware enablement to keep the operating platform reasonably updated with the latest developments and new hardware.
Sometimes, there are some new features in a product which are highly desired by the customer community, and it is impracticable to backport and merge the new features: Then, we release a new version. For example, samba and samba4x packages in Red Hat Enterprise Linux 6: When we launched Red Hat Enterprise Linux 6, we launched Samba version 3 binaries. But then, Samba version 4 came with several features. We added this new samba4x package to address this issue. The same happens with firefox-<xx> packages, where the XX is the upstream version of Firefox.
If you want to learn how we include, test and release new code, keep visiting our blog: we are planning a blog post coming soon that will describe the whole process.
If you want to get a glimpse about how much we import upstream, run the below command:
$ rpm -q --changelog kernel | grep -Eci "(backport|rebase)"
Uh oh, my security scanner says my packages are vulnerable!
Imagine this scenario: My Security team ran a security scan and they hand a report full of red alerts in my server's package versions, stating that they are way outdated and vulnerable to some CVE. And my server is up-to-date with the latest updates! Red Hat, Y U NO UPDATE PACKAGES! /o\
Remember when we said above that we freeze the package version?
That does not mean that we freeze the code as well. Let's use OpenSSL as our example here. We get a security scan stating that my Red Hat Enterprise Linux 7 system is vulnerable to the following CVEs:
Our system currently has openssl-1.0.1e-60.el7. For what it is worth, the -60 highlighted in the version number means the Red Hat build number for that package. It means: Since the code freeze, we have already spun 60 new builds with code fixes of openssl-1.0.1e.
So, in order to find out if I am vulnerable against that list, we need to check the installed OpenSSL changelog. So, run the command:
rpm -q --changelog openssl | grep -E --color \
- fix CVE-2016-2182 - possible buffer overflow in BN_bn2dec()
- fix CVE-2016-6304 - unbound memory growth with OCSP status request
- fix CVE-2016-2108 - memory corruption in ASN.1 encoder
- fix CVE-2016-2109 - possible DoS when reading ASN.1 data from BIO
- fix CVE-2016-0799 - memory issues in BIO_printf
- fix CVE-2016-0705 - double-free in DSA private key parsing
- fix CVE-2014-8176 - invalid free in DTLS buffering code
Whoa! We have 7 fixed vulnerabilities! In the current package!
What about the missing ones, 2016-0798 and 2016-6303?
That will require some Red Hat Bugzilla tinkering. So let's check it out, the first bug. Open the URL https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-0798. (Note: You can always check a CVE in our Bugzilla by using the CVE ID as the bug number).
Hnm. The first thing that caught my eyes in this bug is the Status: Closed / NOTABUG.
Let's keep reading.
Found why this is not a bug for Red Hat:
"This issue does not affect the version of OpenSSL shipped with Red Hat Enterprise Linux 5, 6 and 7, since these packages are compiled without SRP support."
That means: While this is indeed a vulnerability in OpenSSL, the vulnerability is mitigated by the method used by Red Hat to compile that source for the distributed RPM package. WIN!
Let's check the other CVE: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-6303
It is also a "Closed / NOTABUG". Scrolling down, I see comments #4 and #5: "Not vulnerable. This issue did not affect the versions of openssl as shipped with Red Hat Enterprise Linux 4, 5, 6, and 7, as they did not include support for MDC-2." Scored another!
But, why is my security scanner urging me to update to a version that is not present in my Red Hat Enterprise Linux?
Because the scanner tracked only upstream versions and is not aware of Red Hat Enterprise Linux -specific updates.
What if I need something fresher?
Let's take Red Hat Enterprise Linux 7: It was released in June 2014 and is based on Fedora 19, which was released September 2013.
Since we have bumped our base support lifecycle for Operating Systems to 10 years, package aging can be a concern in some scenarios, especially where customers use Red Hat Enterprise Linux packages as their code back-ends, such as PHP, MySQL, Ruby, Python, etc. But what if I need, for example, the latest GCC, PHP, Python, etc.? Am I locked-in? Doesn't Red Hat have something recent and supported?
Yes, we do! Red Hat Software Collections comes to help.
As per our Developers Blog post:
"The tools delivered with Red Hat Enterprise Linux which includes Python, gcc, PHP, Ruby, Perl, and more. These tools have the same support life cycle as Red Hat Enterprise Linux: up to ten years. To maintain compatibility, the major versions of these tools are fixed at the time of the "dot-zero" release of Red Hat Enterprise Linux.
Red Hat Software Collections (RHSCL) are for developers looking for updated tools such as the latest stable versions of dynamic languages, open source databases, web infrastructure, and other essential development tools."
And what is the add-on cost for Red Hat Software Collections? Zero. Nada. Red Hat Software Collections is bundled with your Red Hat Enterprise Linux Subscription (except Self-Support). And it is also supported. Make use of it!
Find instructions on how to activate Red Hat Software Collections in your systems or check the Release Notes to discover all included packages.
In this blog post, you have learned about our release numbering, how to assess if your package is affected by some vulnerability, and how to include fresh developer tools in your subscribed Red Hat Enterprise Linux, at no additional cost.
Rodrigo Freire is a TAM in the LATAM region. He has expertise in Performance and is currently finding his way in the magical OpenStack land. Find more posts by Rodrigo Freire at https://www.redhat.com/en/about/blog/authors/rodrigo-freire
Innovation is only possible because of the people behind it. Join us at Red Hat Summit, May 2-4, to hear from TAMs and other Red Hat experts in person! Register now for only US$1,000 using code CEE17.
A Red Hat Technical Account Manager (TAM) is a specialized product expert who works collaboratively with IT organizations to strategically plan for successful deployments and help realize optimal performance and growth. The TAM is part of Red Hat’s world-class Customer Experience and Engagement organization and provides proactive advice and guidance to help you identify and address potential problems before they occur. Should a problem arise, your TAM will own the issue and engage the best resources to resolve it as quickly as possible with minimal disruption to your business.