Vulnerabilities in Intel CPUs – Is this the end of Hyper-Threading?
There is a major leak in a large part of all CPUs. As with Meltdown and Spectre, there is a lot of fuss about this vulnerability, but now it is also about the hardware properties of the chips. Does this leak mean the end of Hyper-Threading?
What happened again?
Earlier this week, several security researchers revealed a serious vulnerability that affects almost every Intel CPU. That came as an unpleasant surprise, because that company’s CPUs are in more than three-quarters of all computers in the world.
It is not about one leak, but about several vulnerabilities, which were discovered more or less simultaneously by different research teams. Intel classifies all three attacks under the same vulnerability because they exploit the same vulnerabilities in CPUs. The researchers have also set up several websites with their findings and published white papers. Intel has also done that, with a general blog post. They call the bugs under one collective name: Microarchitectural Data Sampling, or MDS. The researchers also gave different names to the vulnerabilities.
| Researchers | Name of leak | Website |
| VU (VUSec) | Rogue In-Flight Data Load (RIDL) | MDSattacks.com |
| University of Leuven | Fallout | MDSattacks.com |
| University of Graz | Zombie load | Zombieloadattack.com/CPU.fail _ _ |
| Intel | Microarchitectural Data Sampling (MDS) | Intel.com |
What are the vulnerabilities?
The vulnerabilities are in speculative execution , an optimization method in which a CPU tries to predict certain tasks or calculations in order to make the processor faster. If such a prediction comes true, the calculation can be performed earlier because the data has already been loaded earlier. If the prediction is incorrect, it is discarded. Different types of buffers are used to make such predictions, such as line-fill buffers , which load data into the cache, and store buffers , which write data to regular memory. With the now discovered vulnerability, the researchers can intercept the data that should have been thrown away from those buffers.
However, an attacker cannot simply determine which data he can read from a buffer. In a proof-of-concept at the VU, the researchers show how they can extract a password from a Linux partition. They have to run the necessary commands many times before they can get the correct data from the buffer. That process also took a long time: about 24 hours. Partly for this reason, Intel puts the vulnerability into perspective. “Practical exploitation of MDS is very complex,” Intel writes in a statement . “But,” the researchers add, “that was under proof-of-concept. We can further optimize it so that it can be done in minutes.” After the security researchers reported the leak to Intel, the manufacturer released a microcode update.
The fact that several leaks were found at once is due to the difference between the types of buffers that can be tapped. “We presented Intel with a proof of concept for leaks from line-fill buffers and load ports,” Stephan van Schaik, one of the VU researchers, tells us. “When we started talking to Intel about this, we found out that the vulnerability could also be exploited via load ports or store buffers. We are not 100% sure about the latter whether our proof of concept also applies to it; we are still investigating that.” That store buffer leak is again what Zombieload is based on: the leak that the Austrian researchers discovered, but also Fallout.
How similar is this leak to Specter and Meltdown?
The vulnerability is initially reminiscent of two other major CPU bugs: Specter and Meltdown. They came out in January last year with a lot of fuss and not without reason. Through these vulnerabilities, information could be extracted directly from the memory of the chips and in both cases it was a problem that could not be patched easily. And, not unimportantly, both MDS and Meltdown specifically involved Intel chips (although the ARM Cortex A75 was also affected by Meltdown).
However, there are a few fundamental differences between MDS on the one hand and Meltdown and Specter on the other. In the case of Meltdown, for example, this involved information that could be read from kernel memory. With MDS, the information is picked from different types of buffers on the chip. According to the researchers, that is one of the fundamental differences; this is a leak of in-flight data , data that is actively used during a session, and not data that is stored in memory or in a cache.
There is also a difference in the way in which you can read data. Van Schaik: “With attacks such as Meltdown, it was much more targeted. There you could point very specifically to an address, to a specific place in the kernel. RIDL does not specifically focus on such a place, but on all information from the buffer. You can then tap it and see what it contains, which makes it very difficult to do anything about it in the software field.”
Does this mean the end of Hyper-Threading?
What makes the leak a lot more complicated is its relationship to simultaneous multithreading, or smt, a process that virtualizes a physical core to multiple logical cores to run multiple threads on a single core. Intel’s variant of this is called Hyper-Threading and that process makes this vulnerability easier to exploit. An update of the microcode from Intel solves that problem somewhat, but not completely, says Van Schaik. “The new microcode presents a barrier for operating system developers. This ensures that data in the buffers before the barrier cannot be leaked by code after the barrier. So when you switch applications, the old process cannot read the new one during speculative execution. So you can no longer read anything via our method. But if you leave Hyper-Threading on, you can’t prevent that barrier from being forced on both threads.
It is not the first time that Hyper-Threading has been mentioned as a potential security risk. For example, in openBSD the process was previously disabled because type libraries and L1 caches were exchanged between threads and could potentially be intercepted. Google has also taken measures by disabling Hyper-Threading in ChromeOS 74, the most recent versions of the operating system. Future versions will receive ‘additional measures’, although it is not immediately clear what these are. Users can still enable the process manually.
Other software makers, such as Apple, Microsoft and various Linux distributions, come with a patch that makes attacks via JavaScript and the browser impossible. An update for Windows is available. Apple has released macOS Mojave 10.14.5 , but it is not available for every Macbook or iMac, because Intel has not released a microcode update for it.
The companies and the researchers also recommend manually disabling Hyper-Threading. That measure is quite severe and can lead to a significant drop in performance in some systems, but exactly how much is difficult to say. That differs per system and per program; several developers are now working on benchmarks. Intel warns that the total performance hit can be up to 40 percent, although that will mainly be in extreme cases.
Google acknowledges that problem. “The decision to enable or disable Hyper-Threading is a trade-off between security and performance.” There are currently no official benchmarks available that show the difference in performance with and without the microcode patch, a difference that will vary by application and configuration in any case. Van Schaik also confirms this. “We don’t have any figures about the performance loss ourselves, but you can estimate when Hyper-Threading can be especially profitable. It depends on your workload; in server applications, for example, it is useful. There you have a lot of clients that connect and as long as you don’t work with a lot of caches and don’t have to send a lot of responses, that’s fine. However, if you have a lot of data in a cache, for example when processing large databases, then Hyper-Threading will not be of much use to you.single clock speed is also usually the most relevant.” Moreover, he adds, it is questionable whether the solutions Intel is proposing might not actually lead to worse performance than if Hyper-Threading was completely disabled.
Intel does not officially recommend disabling Hyper-Threading , but does mention it as a possible measure in further analysis of the issue . Disabling HT alone does not protect against MDS. It leaves the decision to customers themselves. In fact, Intel has rated the four vulnerabilities at the “low to medium” level.
When am I vulnerable?
The biggest impact of the vulnerability lies in two things: the fact that it is a hardware bug, which cannot simply be patched, and its widespread distribution. The leak is in almost every CPU from Intel. All Intel chips from 2008 onwards are vulnerable; these are chips with an architecture from Nehalem. The vulnerability is not only in CPUs for laptops and desktops, but also in the Xeon processors for servers. AMD and ARM chips are not vulnerable to the vulnerability. AMD has also released a statement about this .
It doesn’t take much to exploit the vulnerability. An attacker can already do this if he has access to a machine or a computer’s network, for example by being on the same network in an office environment. It is also possible to execute code with JavaScript via an infected website, for example. Van Schaik: “An attacker really only needs unprivileged code access to a machine. It therefore does not help to work with virtual machines or secure enclaves , for example , because they use the same underlying infrastructures.”
And now?
The big question now is how vulnerable users actually are. At first glance, the leak seems serious: a commonly used technology in almost every CPU of both servers and desktops appears to be vulnerable and there is a lot of sensitive information to steal. On the other hand, carrying out an attack is not so easy. To do this, you must be on the same network as a vulnerable computer or carry out a malware attack, such as via a banner on a website.
Hopefully past Meltdown results provide a guarantee for the MDS future. After all, since that bug was made public along with Specter and Foreshadow, there have been virtually no large-scale attacks using that method. They were predicted by some security researchers. For now, MDS also seems to be holding up pretty well. With updates to operating systems, major risks such as JavaScript remote code executions are prevented and the risk can be minimized by disabling Hyper-Threading. Whether the risk reduction outweighs the decline in performance is another question.