Introduction

Recently researchers at Google’s Project Zero have discovered two major vulnerabilities impacting almost all the processors made in the last 20 years. These vulnerabilities have been named Meltdown and Spectre. In this article, we will describe what these vulnerabilities are, how to check if your system is affected and how to patch an affected Linux system. We will also briefly discuss the potential negative impact of applying the patch.

Let’s now understand what these vulnerabilities are all about.

 

Meltdown
Meltdown affects Intel processors and works by breaking through the barrier that prevents applications from accessing arbitrary locations in kernel memory. In simpler words, the Meltdown vulnerability allows a program to access the kernel’s private memory areas.  These memory locations contain data in unencrypted format giving the attacker access to potentially sensitive information.

 

Spectre
The Spectre vulnerability affects Intel, AMD, and ARM processors and enables an attacker to access sensitive information misleading applications into accidentally disclosing information that would normally be inaccessible, safe inside their protected memory area. This means that a malicious program can trick other programs like your web browsers to reveal password information.

The creator of Linux, Linus Torvalds has publically criticized Intel’s approach towards handling the discovery of these bugs and has raised questions as to how they treat customers even when critical bugs are discovered.
Operating system vendor RedHat has assigned CVE numbers to these vulnerabilities: Spectre (CVE-2017-5753) and Meltdown (CVE-2017-5754)

 

How to check if your Linux system is vulnerable

With a brief understanding of what these vulnerabilities are, we’ll now walk through how to check if your particular system is vulnerable. We’ll be using a Centos 7 system for the demonstrations. A script has been made available on GitHub to check if your system is vulnerable. If you have git installed on your system then you can clone the git repository containing the script as I’ve done or download it and place it on your system.

[[email protected] ~]# git clone https://github.com/speed47/spectre-meltdown-checker
Cloning into 'spectre-meltdown-checker'...
remote: Counting objects: 281, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 281 (delta 4), reused 7 (delta 2), pack-reused 270
Receiving objects: 100% (281/281), 100.53 KiB | 132.00 KiB/s, done.
Resolving deltas: 100% (164/164), done.
[[email protected] ~]# ls -l spectre-meltdown-checker/
total 68
-rw-r--r-- 1 root root 35147 Jan 11 03:38 LICENSE
-rw-r--r-- 1 root root 3057 Jan 11 03:38 README.md
-rwxr-xr-x 1 root root 26351 Jan 11 03:38 spectre-meltdown-checker.sh
[[email protected] ~]#

Now, let’s execute the script as shown below:

[[email protected] spectre-meltdown-checker]# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.23
Checking for vulnerabilities against live running kernel Linux 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: NO (only 27 opcodes found, should be >= 70)
> STATUS: VULNERABLE (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: YES
* 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
> STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)
A false sense of security is worse than no security at all, see --disclaimer
[[email protected] spectre-meltdown-checker]#

From the above output, we can determine that my system was found to be affected by both vulnerabilities. RedHat along with most OS vendors as well as cloud service providers have released fixes for these vulnerabilities in the form of kernel updates.

Related concept:   9 Linux read command examples for Shell scripting

On our Centos system, we can issue the following command to update our operating system kernel.
Note that you must be registered to an online repository receiving the latest software updates in order for this command to work correctly.

[[email protected] ~]# yum update kernel
----------------------------------------------------------output truncated for brevity
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
kernel x86_64 3.10.0-693.11.6.el7 updates 43 M
Updating:
kexec-tools x86_64 2.0.14-17.2.el7 updates 333 k
Updating for dependencies:
dracut x86_64 033-502.el7_4.1 updates 321 k
dracut-config-rescue x86_64 033-502.el7_4.1 updates 56 k
dracut-network x86_64 033-502.el7_4.1 updates 98 k
linux-firmware noarch 20170606-57.gitc990aae.el7 updates 35 M
Transaction Summary
================================================================================
Install 1 Package
Upgrade 1 Package (+4 Dependent packages)
----------------------------------------------------------output truncated for brevity 

After the installation completes we need to reboot our system. After system restart, our operating system should now be using the updated kernel 3.10.0-693.11.6.el7.x86_64.
Let’s run the vulnerability checker script again to verify that the vulnerabilities have been mitigated.

[[email protected] spectre-meltdown-checker]# ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.23
Checking for vulnerabilities against live running kernel Linux 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Jan 4 01:06:37 UTC 2018 x86_64
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: YES (112 opcodes found, which is >= 70)
> STATUS: NOT VULNERABLE (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: YES
* 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
> STATUS: NOT VULNERABLE (PTI mitigates the vulnerability)
A false sense of security is worse than no security at all, see --disclaimer
[[email protected] spectre-meltdown-checker]#

As you can see, the system still appears to be vulnerable to CVE-2017-5715. RedHat is actively working on developing a fix for this and we should see an update in the coming few days.

Related concept:   Ubuntu Tip: Right Click To Open A Document

 

The potential impact of applying the patch
The patch for these vulnerabilities is expected to slow down the machines on which it gets applied. This is because the behavior of CPU processors which caused the vulnerabilities to arise in the first place (referred to as the ability to execute speculative instructions) was providing a performance boost to the system. The degradation in system performance may vary depending on the system and the type of workloads that you run on it. Several researchers claim that Intel deliberately kept the vulnerability open in order to get the slight performance boost over its competitor AMD.

Conclusion

In this article, we discussed what are Meltdown and Spectre vulnerabilities, how to identify them and mitigate them.
We chose RedHat/Centos as our platform of choice for our practical demonstration because it is the more popular operating system across enterprises. Although we’ve used a Centos 7 system running the 3.x version of the Linux kernel, we would like to mention that RedHat has released an updated kernel for the 2.x version as well which runs on RHEL 6/Centos 6 systems. More detailed information about the description and impact of the CVEs on RHEL systems could be found on this link.

Related concept:   CHOWN command in Linux/Unix explained with examples