PortSmash side-channel attack targets Intel Hyper-Threading
The latest side-channel attack against Intel chips, known as PortSmash, targets Hyper-Threading in order to steal data, such as private OpenSSL keys from a TLS server.
Researchers have discovered another side-channel attack against CPUs, this time abusing the simultaneous multithreading architecture in order to steal private data.
The new attack method -- named PortSmash -- was discovered by the team of Billy Bob Brumley, Cesar Pereida Garcia, Sohaib ul Hassan and Nicola Tuveri, based at the Tampere University of Technology in Finland, and Alejandro Cabrera Aldaya of the Universidad Tecnologica de la Habana CUJAE in Cuba.
Brumley described PortSmash as being the result of leakage caused by "execution engine sharing" on simultaneous multithreading (SMT), known on Intel processors as hyper-threading.
"We detect port contention to construct a timing side channel to exfiltrate information from processes running in parallel on the same physical core," Brumley wrote in a post. "We steal an OpenSSL P-384 private key from a TLS server using this new side-channel vector. It is a local attack in the sense that the malicious process must be running on the same physical core as the victim (an OpenSSL-powered TLS server in this case)."
Sumanth Gangashanaiah, director of engineering at ShieldX, said the effectiveness of PortSmash attacks would increase as the number of CPU cores increases.
"For the attack to be successful, the attacker has to run malicious code on the same core as the legitimate code running on the same processor," Gangashanaiah wrote via email. "The challenge here is whether the hypervisor will schedule both the legitimate and malicious code to run on the same core in the case of IaaS. A determined attacker (nation state attackers) could keep trying. If so, the outcome is going to be huge."
CPU side-channel attacks
PortSmash is the latest in a series of side-channel attacks against CPUs that began with the Spectre and Meltdown attacks, which were discovered by multiple independent groups and disclosed in January. Since then, more Spectre variants have been discovered such as NetSpectre, and there has already been a side-channel attack targeting Hyper-Threading, called TLBleed.
Hector Martin, a security researcher based in Tokyo, said via Twitter that side-channel attacks are here to stay.
And yes, Spectre v1 and PortSmash aren't going away. Anyone who knows anything about CPUs knew PortSmash was theoretically possible for years (just someone bothered to finally implement it). Disable HT or petition OSes to do security-domain-aware HT by default.
— Hector Martin (@marcan42) November 2, 2018
Unlike TLBleed, which experts said might be difficult to exploit, PortSmash could prove more dangerous.
"A malicious actor would have nearly zero difficulty to run the malicious process on the same core as the victim process," wrote Justin Jett, director of audit and compliance at Plixer, via email. "Specifically, once the malicious actor knows the process id (PID) of the victim process, they can leverage utilities like taskset to determine which core the process is running on. From there, they can set their malicious process to run on the same core."
Kevin Bocek, chief cybersecurity officer at Venafi, noted via email that "Given the infectious nature of malware and increasing operations in the cloud -- this attack is accessible to many hackers, whether out for profit or hacking a nation state."
PortSmash disclosure
According to Brumley, the team disclosed PortSmash to Intel on Oct. 1. AMD was not notified because the research was only verified on Intel Skylake and Kaby Lake processors, but Martin noted it is theoretically possible on AMD as well.
Also PortSmash should be adaptable to AMD systems with HT (i.e. Zen) and also all the POWER stuff. And it gets worse, because under more specific circumstances and with cleverer exploits, the side channels go beyond HT and to shared caches too.
— Hector Martin (@marcan42) November 2, 2018
Brumley and his team publicly announced PortSmash and provided proof-of-concept code on Nov. 1, the same day Intel provided a patch against the issue.
"My team initially proposed an embargo until 01 Nov in a private communication with Intel Security," Brumley wrote via email. "In the same communication, we gladly offered Intel Security the opportunity to suggest an alternative schedule. They declined to do so at any point during the responsible disclosure process."
Jett noted the sticking point may still be in organizations patching systems.
"There are no hard and fast rules when it comes to reporting and responding," Jett wrote. "Regardless of the amount of time given to Intel, very often patches to systems go undone for far too long. Organizations would very likely remain vulnerable because patches that require systems to be taken offline are done infrequently."
Brumley, Red Hat and other experts suggested the best mitigation would be disabling SMT/Hyper-Threading, if possible, which could negatively impact system performance.
