Site icon UnixArena

How to fix Meltdown & Spectre Vulnerabilities on Redhat Linux?

Lingesh
meltdown-spectre - Redhat

meltdown-spectre - Redhat

Redhat is closely working with Intel and AMD to mitigate the risk of micro-architectural (hardware) implementation issues which are named as Meltdown and Spectre. These vulnerabilities are mostly affecting many modern microprocessors which include Intel, AMD, IBM power and ARM processors. These issues can be overcome by updating Linux kernel, virtualization-related components, and/or in combination with a microcode update (Firmware). To know more about these vulnerabilities, please go through  UnixArena’s initial post about Meltdown and Spectre. This article will provide more resources for identifying the vulnerability and applying the fixes on Redhat operating systems.

Please closely monitor Redhat Support article on a regualr basis to get the latest information. 

 

According to Redhat, 

Spectre:

These variants rely upon the presence of a precisely-defined instruction sequence in the privileged code, as well as the fact that memory accesses may cause allocation into the microprocessor’s level 1 data cache even for speculatively executed instructions that never actually commit (retire).  As a result, an unprivileged attacker could use these two flaws to read privileged memory by conducting targeted cache side-channel attacks. These variants could be used not only to cross syscall boundary (variant 1 and variant 2) but also guest/host boundary (variant 2).

 

Meltdown:

An unprivileged local attacker could read privileged (kernel space) memory (including arbitrary physical memory locations on a host) by conducting targeted cache side-channel attacks.

 

Here is the list of impacted Redhat products :

 

How has Redhat mitigated the risks with new patches?

 

How to identify whether servers are vulnerable or not? 

I think, we no need to check this because all the Intel processors which are released after 1995 are vulnerable. Only AMD processors are not impacted by Meltdown  (Variant 3 ) but vulnerable to variant 1 & 2. However, there are scripts which can provide the results by checking the CPUs & OS.

Script: 1   – Download and execute on Redhat Linux to check vulnerable or not.

Here is the result of my test server using script :1

[root@UARHEL1 tmp]# ./spectre-meltdown-redhat.sh

This script is primarily designed to detect Spectre / Meltdown on supported
Red Hat Enterprise Linux systems and kernel packages.
Result may be inaccurate for other RPM based systems.

/sys/kernel/debug/x86 is mounted and accessible

Some of the following files are not accessible:
/sys/kernel/debug/x86/pti_enabled, /sys/kernel/debug/x86/ibpb_enabled, /sys/kernel/debug/x86/ibrs_enabled

Fallback (non-runtime heuristics) check. Checking dmesg...

Detected CPU vendor is: Intel

Variant #1 (Spectre): Vulnerable
Variant #2 (Spectre): Vulnerable
Variant #3 (Meltdown): Vulnerable

For more information see:
https://access.redhat.com/security/vulnerabilities/speculativeexecution
[root@UARHEL1 tmp]#

 

Script: 2 – Download and execute on Redhat Linux

Here is the result of my test server using script 2 .

[root@UARHEL1 tmp]# ./spectre-meltdown.sh
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64
CPU is Intel(R) Core(TM) i5-4310U CPU @ 2.00GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO
> STATUS:  VULNERABLE  (only 25 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation
*     The SPEC_CTRL MSR is available:  NO
*     The SPEC_CTRL CPUID feature bit is set:  NO
*   Kernel support for IBRS:  NO
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO
* PTI enabled and active:  NO
* Checking if we're running under Xen PV (64 bits):  NO
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer
[root@UARHEL1 tmp]#

 

How to apply the patches to fix the issue?

To mitigate the risk, you must have active Redhat subscription to download the patches. Please visit Redhat Knowledge article to download the patches (From Resolve Tab).

For an example, The following packages must be updated for RHEL 7 .  (RHSA-2018:0007 – Security Advisory)

1. Login to the Linux server as root.All these packages are only associated with Redhat Linux operating system. If you use Redhat Linux for virtualization, you must update the packages for KVM (libvirt) and other associated packages.

2. Navigate to the directory where you have kept the downloaded new RPM packages for update.

3. Run “yum update *” to update the packages.

[root@UARHEL1 tmp]# yum update *
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Examining kernel-3.10.0-693.11.6.el7.x86_64.rpm: kernel-3.10.0-693.11.6.el7.x86_64
Marking kernel-3.10.0-693.11.6.el7.x86_64.rpm as an update to kernel-3.10.0-123.el7.x86_64
Resolving Dependencies
--> Running transaction check
---> Package kernel.x86_64 0:3.10.0-693.11.6.el7 will be installed
--> Processing Dependency: dracut >= 033-502 for package: kernel-3.10.0-693.11.6.el7.x86_64
--> Processing Dependency: linux-firmware >= 20170606-55 for package: kernel-3.10.0-693.11.6.el7.x86_64
---> Package kernel-tools.x86_64 0:3.10.0-123.el7 will be updated
---> Package kernel-tools.x86_64 0:3.10.0-693.11.6.el7 will be an update
--> Processing Dependency: libpci.so.3(LIBPCI_3.3)(64bit) for package: kernel-tools-3.10.0-693.11.6.el7.x86_64
--> Processing Dependency: libpci.so.3(LIBPCI_3.5)(64bit) for package: kernel-tools-3.10.0-693.11.6.el7.x86_64
---> Package kernel-tools-libs.x86_64 0:3.10.0-123.el7 will be updated
---> Package kernel-tools-libs.x86_64 0:3.10.0-693.11.6.el7 will be an update
--> Processing Conflict: kernel-3.10.0-693.11.6.el7.x86_64 conflicts xfsprogs < 4.3.0 --> Processing Conflict: kernel-3.10.0-693.11.6.el7.x86_64 conflicts kmod < 20-9 --> Processing Conflict: kernel-3.10.0-693.11.6.el7.x86_64 conflicts kexec-tools < 2.0.14-3 --> Finished Dependency Resolution

 

4. Once the update is completed , reboot the system & tried to run the script again.

 

5. You must update the server firmware too to mitigate the risks . If its a VMware virtual machine , both hypervisor and server firmware must be updated.

 

The easiest way is just to update the system using yum by directly connecting to Redhat using Subscription Manager.

1. Login to Linux server as root.

# gpk-update-viewer

 

2. Run yum update to update the system.

# yum update

 

Once the required patches are applied, you could see the script results like below.

Script:1  Results

[root@localhost tmp]# ./spectre-meltdown.sh

This script is primarily designed to detect Spectre / Meltdown on supported
Red Hat Enterprise Linux systems and kernel packages.
Result may be inaccurate for other RPM based systems.

/sys/kernel/debug/x86 is mounted and accessible

The following files are accessible:
/sys/kernel/debug/x86/pti_enabled, /sys/kernel/debug/x86/ibpb_enabled, /sys/kernel/debug/x86/ibrs_enabled
Checking files...

Detected CPU vendor is: Intel

Variant #1 (Spectre): Mitigated
Variant #2 (Spectre): Vulnerable
Variant #3 (Meltdown): Mitigated

For more information see:
https://access.redhat.com/security/vulnerabilities/speculativeexecution
[root@localhost tmp]#

 

Script :2  Results: 

[root@localhost tmp]# ./spectre-meltdown-git.sh
Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Dec 28 14:23:39 EST 2017 x86_64
CPU is Intel(R) Core(TM) i5-4310U CPU @ 2.00GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  YES
> STATUS:  NOT VULNERABLE  (106 opcodes found, which is >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation
*     The SPEC_CTRL MSR is available:  NO
*     The SPEC_CTRL CPUID feature bit is set:  NO
*   Kernel support for IBRS:  YES
*   IBRS enabled for Kernel space:  NO
*   IBRS enabled for User space:  NO
* Mitigation 2
*   Kernel compiled with retpoline option:  NO
*   Kernel compiled with a retpoline-aware compiler:  NO
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES
* PTI enabled and active:  YES
* Checking if we're running under Xen PV (64 bits):  NO
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer
[root@localhost tmp]#

 

If you have updated the system firmware for server hardware (which updates the CPU microcode) that will mitigate the risk of Spectre variant 2 as well.

 

update: 17/01/2017

[box type=”note” align=”” class=”” width=””]Further testing has uncovered problems with the microcode provided along with the “Spectre” CVE-2017-5715 mitigation that could lead to system instabilities. As a result, Red Hat is providing a microcode update that reverts to the last known and tested microcode version dated before 03 January 2018 and does not address “Spectre” CVE-2017-5715. In order to mitigate “Spectre” CVE-2017-5715 fully, Red Hat strongly recommends that customers contact their hardware provider for the latest microprocessor firmware updates.[/box]

 

I will update this article once I have more information about major RHEL versions  (5, 6 & 7 ). Hope this article is informative to you. Share it! Comme it !! Be Sociable !!!

Exit mobile version