Intel processors fall under the spell of a new hyperthreading exploit that loots cryptographic keys

In the last 11 months, the processors on our computers and, in some cases, our phones have succumbed to numerous attacks. Wearing names such as Meltdown and Specter, BranchScope, TLBleed and Foreshadow, exploits threaten to siphon some of our most sensitive secrets – passwords or cryptographic keys – from silicon microarchitecture in a way that can not be detected or stopped by traditional methods. security defenses. On Friday, researchers revealed another leak whose existence has already been demonstrated on a wide range of Intel chips and which could also affect other manufacturers.

At the time of the call of the new attack, PortSmash exploits a largely overlooked side channel of Intel's hyperthreading technology. Hyperthreading, an exclusive application of simultaneous multithreading, reduces the time required to perform parallel computational tasks, during which a large number of calculations or executions are performed simultaneously. The increase in performance results from the presence of two logical processor cores sharing the hardware of a single physical processor. Added logic kernels make it easy to divide large jobs into smaller tasks that can be executed faster.

Port conflict as a side channel

In a soon-to-be-released document, researchers explain how they were able to exploit the newly discovered leak to retrieve an elliptic curve private key from a server running a TLS server powered by OpenSSL. The attack, which was carried out on servers equipped with Intel Skylake and Kaby Lake chips and Ubuntu, worked by sending a continuous flow of instructions to a logical core and carefully measuring the time needed to execute them.

The specific timing allowed PortSmash to deduce the key being processed in another logical kernel of the same processor. The leak providing resource is the port conflict, a phenomenon that occurs when multiple instructions using the same physical processor resources are assigned to different ports while waiting to be completed. The vulnerability is indexed as CVE-2018-5407. This applies to computers as well as servers, although the operating vector usually favors the former.

"Our technique can choose from several configurations to target different configurations to target different ports to fit different scenarios, providing a very fine spatial granularity," the researchers wrote. "Moreover, PortSmash is very portable and its execution conditions are minimal, that is to say that it requires no knowledge of cache lines, sets of expulsions, machine learning techniques or reverse engineering techniques.

In an e-mail, Billy Bob Brumley, a professor at the Tampere University of Technology in Finland and one of the authors of the paper, expects chips beyond the Skylake and Kaby Lake architectures to be also vulnerable, with slight changes to the attack code. "We strongly suspect AMD Ryzen's architectures integrating SMT to be vulnerable, but we leave that for future work," he wrote. "(The real reason is that we do not have the [hardware] to test it on the moment, so we have to wait.) "

Brumley stated that the most likely scenario in the real world to maliciously exploit the vulnerability involved a so-called service environment infrastructure, in which a cloud provider hosts all the attributes of a datacenter on-site, including servers, storage and network hardware. and the virtualization layer or hypervisor.

"Personally, I feel that remote connection scenarios are the biggest targeted threat," wrote Brumley. "Here is a [malicious] The user with credentials connects (eg via SSH), compiles the exploit code, and executes it to retrieve information from other processes running in parallel. "

Brumley stated that the exploit had been written in x64 assembly code that ran locally on a vulnerable computer. He stated that he knew of no evidence that the results could currently be replicated using JavaScript uploaded to a website. Given the ability of Spectrum to be exploited in JavaScript, this remains a possibility.

Hyperthreading under the gun

PortSmash is the second processor attack that targets hyperthreading. TLBleed, released in June, also used hyperthreading to determine a private encryption key. The researchers who developed this attack ran a program calculating cryptographic signatures using the Curve 25519 EdDSA algorithm implemented in libgcrypt on a logical core and their attack program on it. another logical heart. They were able to determine the 256-bit encryption key used to calculate the signature by combining an observation of two milliseconds, followed by 17 seconds of search based on automatic learning and a fraction of a second final search by brute force. In this case, the side channel was provided by the translation conversion buffer.

TLBleed was disturbing enough to invite developers to disable hyperthreading in OpenBSD, the operating system that prioritizes security. Brumley also recommended users to disable SMT in their BIOS or choose platforms that do not offer it at all. Better yet, he told Ars, operating system developers should disable SMT at startup.

Alexander Peslyak, a security specialist better known as Solar Designer, called the research "excellent quality". He went on to say that the harbor containment channel has long been obvious and "a fully awaited property". . "

"Maybe the problem is that it has not been documented as such," he wrote. "Perhaps we should have put more effort into making it clearer for everyone in 2005, as it was finally done now."

Peslyak went on to assert that the version of OpenSSL operated by PortSmash was doing things that, in theory, could reveal keys even when SMT is off, although at a pace that would require a lot more time and a lot more resources.

An SSL bug too

Paul Kocher, a cryptography security expert who discovered Specter, admitted that one of the main weaknesses that made PortSmash so alarming was the way OpenSSL performed sensitive operations using branch-based instructions based on secret values.

"This type of leak is something encryption writers already understand very well and know they need to protect themselves," Kocher wrote in an email. it is generally assumed that any situation in which secrets affecting the flow of control, such as the condition of a branch, should be avoided. As a result, I would say that this work describes an OpenSSL bug that can be exploited with the help of well-known problems related to hyperthreading (and perhaps other means too, for example the State of the branch predictor). "

OpenSSL developers have since released an update making PortSmash unworkable. Although the details are not immediately available, they probably involve changes in the way OpenSSL uses or interacts with SMT.

PortSmash paper, entitled Harbor conflicts for pleasure and profit, recommends to always disable SMT, not only to mitigate the threat of PortSmash, but also for that of TLBleed and two similar attacks known as CacheBleed and MemJam. But the authors then recognize the loss of performance that the countermeasure will have on applications using a lot of threads. A defense that would have a lower performance cost would be a proposed modification to the operating systems in order to support logical core isolation requests that applications might perform when performing sensitive tasks. . Selective deactivation of SMT would result in much less performance loss, but it would also require a significant upfront investment, in the form of operating system changes and code libraries.

Another author-recommended approach is for applications to use port-independent code, which "can be achieved through secret-secret secure execution flow coding practices similar to a constant-time execution."

To repeat a previously mentioned point, PortSmash currently poses a threat primarily to people using computers or services that allow unreliable people to use the same physical processor. These users should pay close attention to the research and carefully consider the recommendations. For now, the risk to others is probably low, but that could change with more research.