Addressing Meltdown and Spectre

In the days following the beginning of the New Year, our team became aware of a security flaw regarding the way modern CPUs (central processing unit) predict possible future user actions and store small bits of information in their cache in order to provide near-instant interaction for the user (Speculative Execution) as well the kernel’s memory isolation which is set with the purpose of creating a closed environment for each user/process on the machine.

Both attacks act on a kernel-level and thus can skip the numerous security measures implemented on the machine including the operating system process and user separation. Both attacks are of side-channel type (attacks focused on exploiting side effects from computations in order to extract otherwise unavailable information) and were discovered by Jann Horn (Google Project Zero) as well as 3 other security teams independently from one another at the same time. These vulnerabilities are now called Meltdown and Spectre and categorized in 3 different variants:

CVE-2017-5753 – bounds check bypass
CVE-2017-5715 – branch target injection
CVE-2017-5754 – rogue data cache load

The Flaws

Meltdown

Meltdown got its name from the way it “melts” the memory isolation which purpose is to keep user processes from reading the kernel memory. Meltdown can also read all physical memory mapped in the kernel region due to an inherited flaw of out-of-order execution. This is a type of execution of tasks which modern processors use as a performance boost to schedule subsequent operations to idle execution units of the processor instead of stalling the execution. This means that if a task needs 5 elements to be completed and in its programmed instructions the order is 1,2,3,4 and 5, if element 3 needs more time to be executed the CPU can complete 4 and 5 on the side and then only wait for 3, rearrange them again in their right order and finish the task. Meltdown takes advantage of this timing difference and looks for leaked information as out-of-order memory lookups influence the cache, which then can be detected, extracted and transmitted to a 3^rd party.

Spectre

This is a considerably harder vulnerability to exploit but also harder to mitigate as its effectiveness comes from the speculative executions a CPU does during normal workflow. If you have an “if then – else” structure which is still being decided on, the CPU will try to guess the outcome and attempt to execute ahead of time. When the value which determines the outcome finally arrives, the CPU will either discard or commit the speculative computation it has already made. Spectre attacks can trick the CPU into speculatively executing instructions that should not have been executed in the first place. By detecting which executions were speculative, information can be mapped out within the memory of the system and then leaked via a microarchitectural covert channel.

*Note that, while we did try to provide both an easy to understand explanations as well as some technical details regarding these security flaws, if you want to read a detailed explanation of both Meltdown and Spectre, you can visit the official Google Zero Project report on the matter.

Countermeasures

As some other cloud service providers, we took immediate measures in order to mitigate these vulnerabilities on a kernel-level using CloudLinux’s just released CloudLinux 6 kernel version 2.6.32-896.16.1.lve1.4.49 from their production repository.

Some of you may have experienced a small window of unavailability due to a necessary unscheduled reboot of all Shared Hosting Servers in order for the patch to take effect.

We are also rolling the updated Linux kernel version – 4.14.12 on our VPS and Dedicated Server nodes so no additional actions are required from our customers currently residing on these hosting plans. During the rollout, due to the sporadic release of patches and updates, we simply cannot notify all of our users of exact times when their Servers will be offline. However, with the general and broad nature of Spectre, we are expecting at least a few more mandatory reboots in order to mitigate all of its variations.

We will update this post with more information when such is available.