Security Advisory – Spectre and Meltdown Vulnerabilities

This post is taken from security advisories released by Nutanix and Defiant regarding Spectre and Meltdown, and amended according to other information that has come to light about these vulnerabilities. In general the advice is to bring everything up to the latest patch level you can once a vendor indicates the fix is available in their latest patch bundle.

Spectre and Meltdown Vulnerabilities Summary

The recent media articles on CVE-2017-5715, 5753 and 5754, more recently known as Spectre and Meltdown, focus on flaws or vulnerabilities in a modern processor technique known as Speculative Execution and Branch Prediction. Vulnerability explanations and their associated technical descriptions often assume a high degree of technical expertise in the reader. However, to properly understand the ramifications and actual threat vectors of these vulnerabilities one must understand what Speculative Execution is, and what they provide in today’s computing platforms.

Speculative Execution is the ability of a processor to make reasonable guesses about the future program flow. If the guess is correct then execution has been sped up for that series of instructions. If that guess is incorrect then those paths are cancelled and state changes (registers, memory, etc) are reverted. However, speculative execution also has other side effects such as cache loads, which are not reverted, which can allow for side-channel attacks to leak information. These vulnerabilities are divided into three distinct variants, listed below.

Variant 1 (Spectre) – Bounds Check Bypass (CVE-2017-5753 – CVSSv3 8.2)
Variant 2 (Spectre) – Branch Target Injection (CVE-2017-5715 – CVSSv3 8.2)
Variant 3 (Meltdown) – Rogue Data Cache Load (CVE-2017-5754 – CVSSv3 7.9)

Spectre has been used against multiple processor types to date, including Intel, AMD and ARM, while Meltdown is specifically an Intel processor vulnerability that exploits privilege escalation specific to Intel processors only. Each variant has slightly different ramifications and threat vectors associated with them.

If you would like an in-depth technical overview of the variants and methodology used to exploit them we recommend reading the Google Project Zero documentation. These are linked in the Sources section at the end of this article.

Specific press releases from the CPU manufacturers can be found in the following links for Intel, AMD, and ARM.

CPU Microcode Updates
Microsoft has indicated that microcode updates will also be required. These would come in the form of firmware updates from the computer vendors, and would be applied separately to any patch for overlying software. At present, we have no details of any firmware releases and you should check the suppliers of your own hardware accordingly.

Actual Vectors and Their Impact
Understanding exactly how each variant can be exploited is a key to understanding the method in which you need to patch your datacentre. Each offers a slightly different vector to protect against and each have specific scenarios in which one is vulnerable.

First, one needs to divide systems into virtual vs. bare metal, which naturally divides those sets into user VMs (UVMs) vs. Hypervisors. Since mitigations to this vulnerability, specifically variant 2, rely on a new processor feature provided by microcode update, the separation of bare metal vs. virtual is necessary since in a virtual environment the hypervisor exposes the new feature through to the user VM. Without this interaction (hypervisor exposing the new feature) a true fix to variant 2 is not fully possible.

Variant 1 and Variant 2
Both variant 1 and 2 rely on a malicious attacker manipulating speculative execution of known code. Collectively these two are known as Spectre and both exploit the ability to force a speculative execution in the processor out of bounds, assumingly to an attacker steered location in kernel memory. If the instructions are reordered in a way that the out-of-bounds read (branch prediction) happens prior to its determining operation the value of the out-of-bounds read is stored in cache. Then an attacker, by way of a timing attack, can determine the value resulting in kernel memory leaking.

Variant 3
This variant also uses speculative execution as a jumping off platform, however with a slightly different approach. Variant 3, also known as Meltdown, relies on lack of stringent page table permission checks in the speculative execution path. This exploit relies on the fact that during speculative execution of instruction permission faults, exceptions triggered are suppressed until completion of the whole instruction block. Any subsequent memory access may allocate into L1 cache, even if they reference inaccessible memory locations. As a result, a malicious attacker could read privileged memory by conducting targeted cache side-channel attacks.

Performance and Business Impact

Systems that receive these security updates may experience a performance impact though it is currently difficult to say to what degree. If you are in an operational role, it is important that you evaluate system performance once you have applied OS patches to determine if it will impact your customers.

At an executive level, consider that in a worst-case scenario, system performance may degrade 30% across the board. If you are running your systems at 90% capacity and your financial margins are thin, you may find yourself in a crisis situation which results in raising prices or making other changes to adapt to CPUs no longer delivering the performance to which your business model has become accustomed.

As a customer or end-user, I would reserve judgement on any performance impact until benchmarks are released. If someone tells me that sunspot activity is slowing down my workstation, I tend to notice slowness on my workstation. It is difficult to quantify performance changes until someone does the work to produce accurate and precise benchmarks.

Update: we have had reports of up to 20% performance impact on Postgres running on CentOS – no actual details of the hardware setup. Reports of 5% – 20% slowdown seem to be fairly common, time will tell. However, Google claim to have found a way to mitigate most of the performance impact, which could be good news if this can be widely implemented.

Impact On Hardware Design

Meltdown and Spectre are a new class of vulnerability, both in their sophistication and impact. They use timing attacks to exploit flaws in the underlying hardware we use for a majority of our applications today, both in the cloud and on desktops and devices.

A complete fix for Meltdown and Spectre is going to require a CPU replacement. As CERT says, the solution is to “Replace CPU Hardware”.

It is inevitable that other hardware vulnerabilities like these with wide impact that require hardware changes will emerge in the coming years. We can’t buy new hardware every time this happens. So, a long-term fix may require that we invent a way to dynamically patch the hardware that our software relies on.

Approach to Patching

Each Hypervisor will have their own method of patching these vulnerabilities, and links to the various security advisories are provided later in this article.
User VMs require updates available from the specific general-purpose operating system vendor in use. A list of all possible operating system vendors and their documentation on these vulnerabilities is beyond the scope of this advisory.

Virtual appliances, unlike a general-purpose system, are more purpose built virtual machines with a tighter controlled set of applications and executed code. In many cases, these types of virtual machines do not run unknown user space code. Please consult with the vendor specific to the virtual appliance in question for more information.

As most services are accessed through browsers these days it is vitally important that end user browsers are also updated to help mitigate any use of these vulnerabilities by any malware:

Chrome

Google is recommending that Chrome users enable the strict site isolation feature in Chrome. In your browser visit chrome://flags/#enable-site-per-process to enable strict site isolation. Note: If this setting is not available, make sure your Chrome browser is up-to-date.

Firefox

Updating Firefox to the latest version (v57.0.3 as of the time of this writing) will include mitigations for these attacks.

Internet Explorer / Edge

The latest Windows security updates should include an Internet Explorer / Edge update that mitigates these attacks.

Hypervisors affected

Hypervisor	Fix Release
Nutanix Acropolis	Fix has been created and was scheduled for release after the stated embargo was lifted on January 9th – therefore refer to Nutanix support for release schedule
VMware ESXi version 5.5 VMware ESXi version 6.0 VMware ESXi version 6.5	See guidance available in the following VMware Advisory. https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html
Microsoft Hyper-V (All Supported Versions)	See guidance available in this Microsoft Article. https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution
Citrix XenServer (All Supported Versions)	See guidance available in the following Citrix article. https://support.citrix.com/article/CTX231390

Workaround

None.

Timing of Advisory Release

These vulnerabilities were covered under an industry established embargo period that was scheduled to lift on January 9th 2018, having been known to the CPU manufacturers since June 1st 2017. This was designed so that work could be undertaken with major software vendors to develop patches before the vulnerability was made publicly known, and indeed some patches have been issued early under a generic security cover so may already be installed.

However, many vendors and industry experts have decided to post information prior to the official lifting of that embargo due to media attention and some misinformation present in the mainstream.

On January 1st, speculation started on a blog titled Python Sweetness, about a major vulnerability that was hardware based and involved memory manipulation. On January 2nd, The Register published a story with some details.

Then on January 3rd, GPZ published full details on their blog, resulting in a huge amount of press and official statements emerging.

An extract from Intel’s official statement makes it clear the vulnerabilities were disclosed early:

“Intel is committed to the industry best practice of responsible disclosure of potential security issues, which is why Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available. However, Intel is making this statement today because of the current inaccurate media reports.”

Conclusion

This story is now major news with plenty of coverage and commentary. The authoritative sources for this story are the GPZ blog, the research papers, statements from chip makers Intel, AMD and ARM and the blog posts from cloud providers like AWS and Linode.

Check your vendor blogs and vendor Twitter accounts for updates on security and service interruptions.

For any further advice relating to our hosted systems then please contact us.