Vulnerabilities in Intel CPUs – Is This the End of Hyper-Threading?

There is a major leak in a large part of all CPUs. Just as with Meltdown and Specter, 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 investigators revealed a serious leak that affected almost every Intel CPU. That came as an unpleasant surprise because the company’s CPUs are in more than three-quarters of all computers in the world.

It is not about a single leak, but about different vulnerabilities, which were discovered more or less simultaneously by different investigation teams. The first was discovered by Dutch researchers from VU University Amsterdam, but researchers from KU Leuven found a similar leak, just like scientists from the University of Graz in Austria. Intel places all three attacks under the same vulnerability because they use the same weaknesses in CPUs. The researchers have also set up various websites with their findings and published white papers. Intel has also done that, with a general blog post. They name the bugs under one collective name: Microarchitectural Data Sampling, or MDS. The researchers have also given different names to the vulnerabilities.

Researchers Name of leak Website
VU Amsterdam (VUsec) Rogue InFlight Data Load (RIDL)
KU Leuven Fallout
University of Graz Zombie load /
Intel Microarchitectural Data Sampling (MDS)

What are the vulnerabilities?

The vulnerabilities are in speculative execution, an optimization method where a CPU tries to predict certain tasks or calculations to make the processor faster. If such a prediction comes true, the calculation can be performed earlier because the data was already 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 the regular memory. With the vulnerability now discovered, the researchers can intercept the data that should have been discarded from those buffers.

However, an attacker cannot simply determine which data he can read from a buffer. In a proof-of-concept from the VU, the researchers show how they can get a password from a Linux partition. They have to run the necessary commands very often before they can get the right data from the buffer. That process also took a long time: around 24 hours. Partly for this reason Intel puts the vulnerability in perspective. “Practical exploitation of MDS is very complex,” Intel writes in a statement . “But,” the researchers add, “that was under the proof-of-concept. We can further optimize it so that it can be done within minutes.” After the security investigators had reported the leak to Intel, the manufacturer released a microcode update.

The fact that different leaks were found at one time is due to the difference between the types of buffers that can be tapped. “We presented a proof of concept to Intel to leak from line-fill buffers and load ports,” says Stephan van Schaik, one of VU researchers at Tweakers. “When we discussed this with Intel, we discovered that the leak could also be exploited via load ports or storebuffers. Of the latter, we are not 100% sure whether our proof of concept also applies to it; we are still investigating that. ”That storebuffer leak is again what Zombieland is based on: the leak that the Austrian researchers discovered, but also Fallout.

The vulnerability is in speculative execution and the buffers that are used for this

To what extent does this leak resemble Specter and Meltdown?

The vulnerability initially reminds a lot of two other large CPU bugs: Specter and Meltdown. They came out in January last year with great fuss and not without reason. Through these vulnerabilities, information could be taken directly from the memory of the chips and in both cases it was a problem that could not be patched. And not unimportantly: both MDS and Meltdown were specifically about Intel chips.

There are, however, a few fundamental differences between MDS on the one hand and Meltdown and Specter on the other. In the case of Meltdown, for example, it concerned information that could be read from the kernel memory. With MDS the information is picked from the chip from different types of buffers. There is, according to the researchers, 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 you can read data. Van Schaik: “For attacks such as Meltdown, that was much more focused. There you could point very specifically to an address, to a specific place in the kernel. RIDL does not specifically focus on such a location, but on all information from the buffer. You can then tap it and see what it contains, and that makes it very difficult to do something about it in the area of ​​software. ”

For example, RIDL tries to intercept the line fill buffer

Does this mean the end of Hyper-Threading?

What makes the leak a lot more complicated is the relationship with simultaneous multithreading, or smt, a process in which a processor uses several physical cores to perform the same calculation. Intel’s variant is called Hyper-Threading and that process makes it easier to exploit this vulnerability. An update of the microcode from Intel solves that problem somewhat, but not completely, says Van Schaik. “The new microcode provides a barrier for developers of operating systems. This ensures that data in the buffers before the barrier cannot be leaked by code after the barrier. So if you switch applications, the old process cannot read the new during speculative execution. So you can no longer read anything via our method. But when you leave Hyper-Threading on, you cannot 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, the process in openBSD has already been 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 ‘extra measures’, although it is not immediately clear which they 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. 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.

The companies and the researchers themselves also recommend that you disable Hyper-Threading manually. That measure is quite severe and can lead to a significant decrease in performance in some systems, but it is difficult to say exactly how much that is. That differs per system and per program; various developers are now working on benchmarks. Intel warns that the total performance hit can go up to forty percent, although that will be especially in extreme cases.

The problem with the vulnerability
is that it is a hardware vulnerability. 
Google acknowledges that problem. “The decision to turn Hyper-Threading on or off is a trade-off between safety 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, in any case, be different per application and configuration. Van Schaik confirms that too. “We don’t have any figures about the loss of performance ourselves, but you can estimate when Hyper-Threading can mainly deliver a profit. It depends on your workload; for example, it is useful for server applications. There you have many clients that connect and as long as you don’t work with many caches and don’t have to send many responses, that’s fine. However, if you have a lot of data in a cache, for example when processing large databases, then Hyper-Threading is not very useful. single clock speed is also usually the most relevant. ”In addition, he adds, it is questionable whether the solutions proposed by Intel do not lead to poorer performance than when Hyper-Threading is completely disabled.

Intel does not officially recommend turning off Hyper-Threading, but it does mention it as a possible measure in a further analysis of the problem. “Only switching off HT does not protect against MDS,” the company writes. It leaves the decision to customers themselves. Intel has even rated the four vulnerabilities at the ‘low to medium’ level.

When am I vulnerable?

The biggest impact of the vulnerability is in two things: the fact that it is a hardware bug so that it is not easy to patch, and the widespread nature of it. The leak is in almost every CPU from Intel. All Intel chips from 2008 are vulnerable; it is about chips with 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 issued a statement about this .

The researchers at VU Amsterdam have put a tool on their website that can be used to check whether a system is vulnerable to MDS.

Tool from KU Leuven and VU Amsterdam to test the vulnerability of a system for MDS

Not much is needed to exploit the vulnerability. An attacker can already do that if he has access to a machine or the network of a computer, for example by sitting on the same network in an office environment. It is also possible to execute code with JavaScript via for example an infected website. Van Schaik: “An attacker really only needs unprivileged code access to a machine. It does not help, for example, to work with virtual machines or secure enclaves , because they use the same underlying infrastructures. ”

And now?

The big question now is how vulnerable users are. At first, the leak seems serious: a widely used technology in almost every CPU of both servers and desktops appears to be vulnerable and much sensitive information can be stolen. On the other hand, carrying out an attack is not that easy. To do this, you must be within the same network as a vulnerable computer or carry out a malware attack, such as via a banner on a website.

Hopefully, Meltdown results achieved in the past offer a guarantee for the MDS future. After all, since that bug was made public together with Specter and Foreshadow, there have been virtually no large-scale attacks with that method. They were predicted by some security researchers. For the time being, MDS also seems to be reasonably well contained. With updates to operating systems, major risks such as JavaScript remote code executions are stopped and by eliminating Hyper-Threading, the risk can be properly minimized. Whether the risk reduction outweighs the decline in performance is another question.