BT

PortSmash is the Latest Side-Channel Attack Affecting Intel CPUs

| by Sergio De Simone Follow 21 Followers on Nov 04, 2018. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

SMT but only within process.... by Ian Ringrose

Maybe SMT is only a safe option when both threads have complete access to each other's memory, for example when they are part of, the same process.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss
BT