Spectre-NG
About This Article
On May 3, heise reported about 8 new processor vulnerabilities called Spectre-NG, originally german, then translated into english. This document describes what we currently know about this, what we don't know, what we expect to happen and how we plan to deal with it.
What We Know
As of today (early morning of 2018-05-04), we only have the publicly available information. We have reached out to heise and to intel directly and also via our partner Huawei to gain more insight. Unfortunately, we expect to not being allowed to share much of what we learn through that publicly.
heise talks about 8 new CPU flaws collectively called Spectre-NG (next generation) and claims that these have been validated to be real and exploitable on intel x86(-64) CPUs. The language suggests that we have similar information disclosure (ID) issues as we saw with Meltdown and Spectre at the beginning of this year, allowing attackers to leverage microarchitectural knowledge (e.g. about BTB aliasing or cache architecture) to create side-channel attacks (such as cache timing) to retrieve architecturally protected information. In particular, the report suggests that virtual machines might be able to get read access to data from the hypervisor or other VMs, which is a particular concern for users of shared virtualized infrastructure, such as cloud users.
This is of course the same pattern as Spectre-v2.
(Spectre-v2 has been mitigated meanwhile by hypervisors and operating system kernels using new features provided by update CPU microcode as well as software techniques such as retpolines; we have published our progress with applying all patches everywhere regularly.)
The language further suggests that at least one of the attack scenarios is easier to perform than the Branch Target Injection attacks abusing the Spectre-v2 vulnerability, which were difficult to perform and needed code taking into account the specific microarchitectural details of the attacked CPU. intel rates 4 of the 8 issues as highly critical.
The article suggests that we will see a set of publications and updates in May from intel and Microsoft and another set later this summer.
At least some of the attack scenarios also seem to defeat the special memory protection and encryption mechanisms that have been implemented in recent CPUs to add an additional barrier against attackers.
What We don't Know
ARM big-core CPUs are again likely to be affected as well, whereas the situation for AMD is less clear.
We don't know whether all modern intel CPUs are affected (like with the original Meltdown and Spectre issues) or whether this hits a smaller subset this time.
We don't know how the mitigation will look like and whether there are effective workarounds, real fixes and whether we will again see a significant performance impact.
It's possible that the existing workarounds for Meltdown and Spectre might help or even fully mitigate the new attack scenarios, but we don't know.
The language suggests this is again a information disclosure (ID) issue, and nothing hints at this falling into a different category (such as Elevation of Privileges or Remote Code Execution which would be even more serious), but this is not 100% clear.
Guesswork
The unclarity around AMD CPUs suggests that we have a situation that is similar to either Meltdown (where AMD is more careful doing speculations across privilege boundaries) or Spectre-v2 (where AMD is lucky to have less aliasing in the BTB cache making exploitation significantly harder). Maybe it's the return stack (RSB) this time?
Given the situation with Spectre-v2 and the fact that intel and Microsoft are involved with future announcements, we would expect that we will again see microcode updates that enable new CPU features that then hypervisors and OS kernels can use to prevent attacks or at least make them a lot harder.
I expect that some of the 8 new scenarios are successfully mititgated using the existing mitigation mechanisms (kPTI, retpolines, IBC, user pointer sanitization), but not all of them, so new microcode and patches will still be required.
I would expect again that these patches will cost some performance, although with the high price for kPTI and especially IBC, the add-on cost will probably not be that impressive any more. Question is of course whether those enjoying the significantly smaller performance impact of retpolines (with minimal IBPB support) will now be forced to use more heavy-handed IBC-like mechanisms again.
As at least one exploit seems to be easier to exploit than Spectre-v2, the new attacks mean that the urgency to apply the new patches (despite all the performance impact) will be even higher this time.
OTC Reaction
It's unfortunate to see the prediction come true that the three attack scenarios will not be the last ones leveraging microarchitectural details from side-effects of speculative out-of-order exection.
Obviously we are collecting information and closely monitor the situation. As issues become public and patches available, we will again deploy them very quickly to ensure the full separation between VMs on our platform. We do depend on the availability of patches though -- we do hope that responsible disclosure mechanisms did succeed in giving CPU and OS vendors enough time to provide patches before attackers can leverage the information to build exploits.
Patching means that we will deploy new microcode quickly (assuming that intel has learned from the last disaster and provides stable uCode directly), patch our hypervisors and provide updated public images with patched kernels (and also including updated microcode for BareMetal). Thanks to our ImageFactory, we can deliver a full set of validated new Linux images within hours.
Please be aware that the Spectre and Meltdown attacks require an attacker to run custom code on the attacked machine -- in a cloud scenario, this means that a neighbor VM must have been hacked already or needs be owned by an evil customer.
Customers that are concerned about sharing compute resources in VMs on hosts shared with other customers do have the option to use Dedicated Hosts in OTC. This will ensure that only VMs from the same customer run on a given host, thus avoiding information disclosure to other customers. For customers using automation to roll out their cloud landscape on OTC, this could be done comparably easily just adding the appropriate scheduler-hints to the deployment recipes. Moving existing VMs is somewhat harder, but possible as documented in this article. Bare Metal on OTC is an alternative to Dedicated Hosts of course.
Update 2018-05-22
Variants 3a and 4 have been published on May 21. See our assessment here.