PortSmash attack blasts hole in Intel's Hyper-Threading CPUs, leaves with secret crypto keys

Malware already on machines can exploit SMT using side-channel techniques to snatch private info

Cargo ship in port, burning

Brainiacs in Cuba and Finland have found a new side-channel vulnerability in Intel x64 processors that could allow an attacker to sniff out cryptographic keys and other privileged information.

Following disclosure of the flaw to Intel at the beginning of October, boffins at the Tampere University of Technology in Finland and Technical University of Havana, Cuba, today published proof-of-concept they're calling PortSmash.

The research team used the PoC to steal an OpenSSL (version 1.1.0h or less) P-384 private key from a TLS server. (Subsequent versions of OpenSSL aren't susceptible.)

To pull off this secret surveillance, the exploit code must run on the system under attack, specifically on the same CPU core as the process you want to pry into. That means it can't be used to eavesdrop on software remotely, or easily on the same host, but it could be useful for determined miscreants and snoops who have managed to infiltrate someone else's computer. You basically have to already be able to run your own evil code on a machine in order to PortSmash it.

In a post to a security mailing list, Bill Brumley, assistant professor in the department of pervasive computing at Tampere, said the information leakage was made possible thanks to Intel's implementation of simultaneous multi-threading, known as Hyper-Threading.

SMT works by allowing, typically, two separate running programs to share the same CPU core at more or less the same time: two threads in one or more processes can run alongside each other in a single processor core. If you have four cores, and two of these SMT hardware threads per core, that's effectively eight cores per processor as far as application software is concerned, which means more stuff can be executed per second. SMT therefore boosts performance in some cases, and in others, it can reduce performance, depending on the workload type.

The downside is that it is possible for code in one hardware thread to look over the shoulder of code in the other hardware thread on the same core, and work out what its partner is doing. It can do this by studying patterns of access to caches, or timing how long it takes to complete an operation. This is why developers of cryptographic software, especially, are encouraged to build in defenses to thwart side-channel eavesdropping.

"We detect port contention to construct a timing side channel to exfiltrate information from processes running in parallel on the same physical core," as Brumley put it.

No, this isn't the official TLBleed logo (unless you want it to be)

Meet TLBleed: A crypto-key-leaking CPU attack that Intel reckons we shouldn't worry about

READ MORE

Thus, the attack works by running the PortSmash process alongside a selected victim process, on the same CPU core, with each process using one of the core's two SMT hardware threads. The PortSmash code then measures timing discrepancies to snoop on the operations performed by the other process, and gradually discern its protected data.

That means if the spied-upon process is performing some kind of cryptography, it is possible for the PortSmash process sharing the same CPU core to extract secret information, such as an decryption key, from its victim program

The fix, Brumley suggests, is to disable SMT/Hyper-Threading in the processor chip's BIOS. OpenBSD already disables Intel's Hyper-Threading for security reasons.

The PoC, Brumley says, works out of the box for Intel's Skylake and Kaby Lake, though it hasn't been tested on other Intel chips. He suggests it may work for other SMT architectures – such as AMD's Zen CPU family – if modifications are made to the code.

A CVE has been proposed, CVE-2018-5407, however, Intel doesn't appear to think it's worthy of a patch. For one thing, it has nothing to do with this year's speculative execution flaws: Spectre, Meltdown, and the like.

In a statement emailed to The Register, an Intel spokesperson suggested any risk can be mitigated through existing software protections, such as writing code that is resistant to SMT side-channel attacks. Chipzilla is, essentially, taking a line suggested in the mailing list discussion of the flaw that this isn't so much a vulnerability as "a fully expected by-design property" arising from SMT.

"Intel received notice of the research," the chipmaker's spokesperson said. "This issue is not reliant on speculative execution, and is therefore unrelated to Spectre, Meltdown or L1 Terminal Fault. We expect that it is not unique to Intel platforms. Research on side-channel analysis methods often focuses on manipulating and measuring the characteristics, such as timing, of shared hardware resources. Software or software libraries can be protected against such issues by employing side-channel safe development practices."

Intel's spokesperson repeated its assertion that the company takes protecting customer data seriously and considers it a top priority.

A spokesperson for AMD told us they're looking into it: "At AMD, security is a top priority and we are continually working to ensure the safety of our users as new risks arise. We are investigating the PortSmash side-channel vulnerability report, which we just received, to understand any potential AMD product susceptibility." ®




Biting the hand that feeds IT © 1998–2018