Researchers have devised a new kind of timing attack to steal information from a different process running on the same core with simultaneous multithreading (SMT)/hyper-threading enabled. By carefully measuring port contention delays when sending instructions to a shared core, the researchers could recover a private key from a different process. Intel CPUs are probably not the only ones affected.
As Billy Bob Brumley, a professor at the Tampere University of Technology in Finland and one the authors of the research along with Alejandro Cabrera Aldaya of Universidad Tecnológica de la Habana (CUJAE), Habana, Cuba, and others, explained:
We detect port contention to construct a timing side channel to exfiltrate information from processes running in parallel on the same physical core.
Their approach made it possible to steal an OpenSSL (<= 1.1.0h) P–384 private key from a TLS server running on Skylake or Kaby Lake CPUs.
To understand what port contention is, one should keep in mind that modern processors have multiple ports they assign to different instructions waiting for completion on a shared core. For example, a processor could have two ports for executing load operations. This would allow that processor to schedule two instructions doing a load at the same time. When ports get exhausted, a process will have to wait, thus introducing a measurable delay.
All the details about the attack will be disclosed in a yet-to-be-published paper submitted to IACR under the title "Port Contention for Fun and Profit", but it seems reasonable to say that this vulnerability could be seen almost as a by-design property of SMT, albeit not trivial to exploit. What is novel, though, is the reproducibility of the attack, as Brumley remarks:
Pull the code, follow the instructions. You’ll see the signals we used in the attack. No address dependencies, adapting to cache geometry, etc. -- it just works out of the box.
This might lead vendors to reconsider the viability of using SMT, especially on shared Cloud machines. Indeed, a closely related vulnerability, TLBleed, which also exploited hyperthreading, was disclosed a few months ago. As a reaction to that, the OpenBSD project introduced a configuration mechanism to disable hyperthreading, and additionally disabled it by default, considering there to be serious risks.
On a related note, the attack described by Brumley and others effectively exploits a weakness in OpenSSL 1.1.0h, which branches upon a secret, thus making it possible to infer the private key from measuring contention times. OpenSSL has already patched the relevant code and protected a defense against that specific attack.
In a statement to several media outlet, Intel stated that the issue is not reliant on speculative execution and should thus be considered unrelated to Spectre, Meltdown, or L1TF attacks.