Intel CPUs fall to new hyperthreading exploit that pilfers crypto keys
Over the past 11 months, the processors running our computers, and in some cases phones, have succumbed to a host of attacks. Bearing names such as Meltdown and Spectre, BranchScope, TLBleed, and Foreshadow, the exploits threaten to siphon some of our most sensitive secrets—say passwords or cryptographic keys—out of the silicon microarchitecture in ways that can’t be detected or stopped by traditional security defenses. On Friday, researchers disclosed yet another leak that has already been shown to exist on a wide range of Intel chips and may also affect other makers, too.
PortSmash, as the new attack is being called, exploits a largely overlooked side-channel in Intel’s hyperthreading technology. A proprietary implementation of simultaneous multithreading, hyperthreading reduces the amount of time needed to carry out parallel computing tasks, in which large numbers of calculations or executions are carried out simultaneously. The performance boost is the result of two logical processor cores sharing the hardware of a single physical processor. The added logical cores make it easier to divide large tasks into smaller ones that can be completed more quickly.
Port contention as a side channel
In a paper scheduled for release soon, researchers document how they were able to exploit the newly discovered leak to recover an elliptic curve private key from a server running an OpenSSL-powered TLS server. The attack, which was carried out on servers running Intel Skylake and Kaby Lake chips and Ubuntu, worked by sending one logical core a steady stream of instructions and carefully measuring the time it took for them to get executed.
The specific timing allowed PortSmash to deduce the key being processed in another logical core of the same processor. The resource providing the leak is port contention, a phenomenon that happens when multiple instructions using the same physical processor resources get assigned to various ports to await completion.
“Our technique can choose among several configurations to target different configurations to target different ports in order to adapt to different scenarios, thus offering a very fine spatial granularity,” the researchers wrote in the paper. “Additionally, PortSmash is highly portable and its prerequisites for execution are minimal, i.e., does not require knowledge of memory cache-lines, eviction sets, machine learning techniques, nor reverse engineering techniques.”
In an email, Billy Bob Brumley, a professor at the Tampere University of Technology in Finland and one of the authors of the paper, said he expects that chips beyond the Skylake and Kaby Lake architectures are similarly vulnerable with slight modifications to the attack code. “We strongly suspect AMD Ryzen architectures which feature SMT are vulnerable, but we leave that for future work,” he wrote. “(The real reason is we don’t have the [hardware] to test it on at the moment, so we have to wait.)”
Brumley said the most likely real-world scenario for maliciously exploiting the vulnerability is in so-called infrastructure as a service environments, in which a cloud provider hosts all the trappings of an on-premises data center, including the servers, storage and networking hardware, and the virtualization or hypervisor layer.
“Personally speaking, I feel remote login scenarios are the biggest targeted threat,” Brumley wrote. “Here, a [malicious] user with credentials logs in (e.g. via SSH), compiles the exploit code, and runs it to extract information from other processes running in parallel.”
Brumley said the exploit was written in x64 assembly code that runs locally on a vulnerable computer. He said he knows of no evidence the results can currently be reproduced using JavaScript downloaded from a website. Given the ability of Spectre to be exploited in JavaScript, it remains a possibility.
Hyperthreading under the gun
PortSmash is the second processor attack that targets hyperthreading. TLBleed disclosed in June also used hyperthreading to determine a private encryption key. The researchers developing that attack ran a program calculating cryptographic signatures using the Curve 25519 EdDSA algorithm implemented in libgcrypt on one logical core and their attack program on the other logical core. They were able to determine the 256-bit encryption key used to calculate the signature with a combination of two milliseconds of observation, followed by 17 seconds of machine-learning-driven guessing and a final fraction of a second of brute-force guessing. The side channel in that case was provided by the translation lookaside buffer.
TLBleed was worrisome enough to prompt developers to disable hyperthreading in OpenBSD, the operating system that prioritizes security. Brumley also recommended that users disable SMT in their BIOS or choose platforms that don’t offer it at all. Better yet, he told Ars, OS developers should disable SMT at boot time.
On a vulnerability disclosure group thread discussing PortSmash, Alexander Peslyak, the security specialist better known as Solar Designer, praised the research as “top notch.” He then said that the port contention side-channel has long been obvious and “a fully expected property.”
“Maybe the problem is it wasn’t documented as such,” he wrote. “Maybe we should have put more effort into making it more obvious to everyone in 2005, like it’s finally done now.”
Peslyak went on to say that the version of OpenSSL exploited by PortSmash was doing things that in theory could leak keys even when SMT is turned off, albeit at a pace that would require much more time and many more resources.
An SSL bug, too
Paul Kocher, the cryptography security expert who discovered Spectre, agreed that a key weakness that makes PortSmash so alarming was the way OpenSSL carried out sensitive operations using branch instructions that’s based on secret values.
“This kind of leakage is something that crypto library authors already understand pretty well and know they need to protect against,” Kocher wrote in an email “E.g. it’s typically assumed that any situation where secrets to affect the control flow, such as the condition for a branch, needs to be avoided. As a result, I’d say that this work describes an OpenSSL bug that can be exploited using well-known issues with hyperthreading (and perhaps other ways as well, e.g. branch predictor state).”
OpenSSL developers have since released an update that makes PortSmash infeasible. While details weren’t immediately available, they likely involve changes in the way OpenSSL uses, or interacts with, SMT.
The PortSmash paper, titled Port Contention for Fun and Profit, continues to recommend fully disabling SMT, not only to blunt the threat of PortSmash, but also those of TLBleed and two similar attacks known as CacheBleed and MemJam. But the authors go on to recognize the performance loss the countermeasure will have on thread-intensive applications. A defense that would have less of a performance cost is a proposed change to OSes to support logical core isolation requests that apps could make when carrying out sensitive tasks. The selective SMT disabling would inflict a much lower performance penalty, but it also requires a large upfront investment in the form of changes to OSes and the code libraries.
Another approach the authors recommend is for applications to use port-independent code, which “can be achieved through secret-independent execution flow secure coding practices, similar to constant-time execution.”
To repeat a point made earlier, PortSmash currently poses a threat mainly to people using computers or services that allow untrusted people to use the same physical processor. These users should pay close attention to the research and carefully consider the recommendations. For the time being, the risk to others is likely low, but that could change with more research.
