Patching Spectre / Meltdown on RHEL 5.11

Latest response

I'm relatively new to supporting Linux, but my new role has me doing some patching for our Linux boxes (both virtual and physical).

First of all...

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.11 (Tikanga)

I ran Red Hat's script to see if we are vulnerable to the Spectre/Meltdown issue, and we are. Supposedly, RedHat has patches for us. To complicate things, apparently "#yum updateinfo" doesn't work on Red Hat 5.11.

Doing a "yum list kernel" shows:

# yum list kernel
Loaded plugins: product-id, security, subscription-manager
...
Installed Packages
kernel.x86_64                                              2.6.18-404.el5                                              installed
kernel.x86_64                                              2.6.18-408.el5                                              installed
kernel.x86_64                                              2.6.18-416.el5                                              installed
Available Packages
kernel.x86_64                                              2.6.18-419.el5                                              rhel-5-server-rpms

The command "yum info-security" shows a few older updates (use-after-free) are available, but nothing for the Spectre/Meltdown patches (CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753).

Any ideas on why these latest patches aren't showing up for me?

Thanks for any help you can provide.

SS
Log in to join the conversation

Responses

Christian Labisch's picture Guru 9710 points
2 March 2018 6:40 PM

Hi Stephen,

The RHEL 5 edition is "kinda EOL" ... and for this reason not maintained with higher priority.
End of Maintenance Support 2 (Product retirement) took effect at the end of March 2017.
I recommend to switch to the latest stable, with high priority supported, edition RHEL 7.4. :)

Regards,
Christian

SS Newbie 10 points
2 March 2018 7:09 PM

Thank you for your answer.

It was my understanding that we have a subscription which extends support of our operating system version for security-related updates and patches.

# subscription-manager status
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Current

We do have plans to update soon, but as I'm sure you're aware, jumping from RHEL 5.x to RHEL 7.x is easier said than done on a heavily used/abused production network. In the meantime, we are hoping to mitigate against (as best can) the aforementioned vulns.

Thomas Jones's picture Guru Community Member 3711 points
3 March 2018 12:22 AM

While RHEL5's extended support is through 2020 patches for the various releases tend to be staggered. RHEL 7 gets addressed first, then RHEL 6 and then, finally, RHEL 5. As RHEL 5 gets closer to its final sunset, the release-to-release staggering is likely to stretch out: it's a natural consequence of supporting something that fewer an fewer customers are paying for - justification for allocation of limited engineering resources tails out. Under normal circumstances this means that a few weeks to a few months after something appears for RHEL 7 you'd see something on RHEL 5.

hat said, this particular vulnerability has proven to be far from "normal". Several vendors who released patches for OSes that were in their primary support portion of their lifecycle had to either wholly-retract or severely-caveat their first few patch-offerings. This was due to a combination of the earlier offerings not actually fixing the problems, causing serious performance-impacts and/or, in some cases, rendering systems highly unstable. On the plus side for you is that many of these issues were discovered (presumably) before any (meaningful) steps were taken to create fixes for RHEL 5. Down side is you probably won't see anything for RHEL5 until well after everything for RHEL7 has been suitably fixed and tested.

Christian Labisch's picture Guru 9710 points
3 March 2018 10:52 AM

Hi Stephen,

Good decision to upgrade soon ... the coming point release RHEL 7.5 would be a reasonable time to switch.
There have been so many improvements since RHEL 5 which should make your decision somewhat easier. :)

Regards,
Christian

Thomas Jones's picture Guru Community Member 3711 points
5 March 2018 12:57 PM

Would likely be an easier decision if EL7 wasn't non-trivially different to administer, you mean. Lotta people have difficulties with making the jump to things like systemd (and many people either wholly disable firewalld or otherwise try to run it like iptables).

Christian Labisch's picture Guru 9710 points
5 March 2018 1:15 PM

True Thomas, but at some point we'll have to make that decision nevertheless, otherwise we would loose contact to ongoing evolution. Compare it with Windows : Who could successfully accomplish common tasks with Windows 3.1 in these days ? So I think that improvement beats convenience. :)

Regards,
Christian

Thomas Jones's picture Guru Community Member 3711 points
5 March 2018 1:37 PM

More a comment on people needing to be more-prepared when moving from RHEL 5 (or even 6) to RHEL 7 than when moving from RHEL 5 to RHEL 6. It's definitely not a move you want to undertake lightly.

Christian Labisch's picture Guru 9710 points
5 March 2018 1:45 PM

I agree, Thomas - there is absolutely much more to consider compared to a point release upgrade. :)

Regards,
Christian

Jonathan Groves's picture Active Contributor 195 points
5 March 2018 9:11 AM

Hi Stephen,

Check that you do have a valid ELS subscription assigned to your server

# subscription-manager list
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+
Product Name:   Red Hat Enterprise Linux Server
Product ID:     69
Version:        5.11
Arch:           x86_64
Status:         Subscribed
Status Details:


Product Name:   Red Hat Enterprise Linux Server - Extended Life Cycle Support
Product ID:     204
Version:        5
Arch:           x86_64
Status:         Subscribed
Status Details:

If so, you will then be able to install the latest kernel to patch these vulnerabilities

# yum check-update
Loaded plugins: enabled_repos_upload, package_upload, product-id, security, subscription-manager

rhel-5-server-els-rpms                                                                                                                                     17416/17416
rhel-5-server-rpms                                                                                                                                            17331/17331

Skipping security plugin, no data

kernel.x86_64                                                               2.6.18-426.el5                                                       rhel-5-server-els-rpms
kernel-headers.x86_64                                              2.6.18-426.el5                                                       rhel-5-server-els-rpms

Uploading Enabled Repositories Report
Loaded plugins: product-id

Kind Regards Jonathan Groves

JM Community Member 29 points
28 March 2018 10:25 AM

Just to note that we've found kernel-2.6.18-426 bricks RHEL5.11 on Xen. The workaround as supplied is to edit /etc/sysconfig/kernel after applying the patch and finding oneself unbootable.

"Issue: With New kernel (kernel-xen-2.6.18-426.el5.x86_64) we are not able to boot up the system. Grub,conf is not getting update properly. Default entry is setting to 1.

Solution Provided by Red Hat : /etc/sysconfig/kernel change DEFAULTKERNEL=kernel to DEFAULTKERNEL=kernel-xen. Run yum update again. Verify grub.conf entry if correct and then go for a reboot. "

Doesn't feel very enterprise-class, but hey.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.