(http://i.postimg.cc/66hk46pV/portsmash.jpg)
A new side-channel vulnerability has been discovered called PortSmash that uses a timing attack that to steal information from other processes running in the same CPU core with SMT/hyper-threading enabled. Utilizing this attack, researchers were able to steal the private decryption key from an OpenSSL thread running in the same core as their exploit.
SMT/Hyper-threading is when one physical CPU core is split into two virtual logical cores that can be used to run two separate process threads at once. This method can increase performance as the two threads will utilize idle CPU resources more efficiently to execute instructions faster.
A side channel timing attack is when an attacker analyzes how fast a thread executes particular instructions and utilizes that information to work backward to discover what data was used as input.
The PortSmash vulnerability was discovered by researchers Billy Bob Brumley, Cesar Pereida Garcia, Sohaib ul Hassan, and Nicola Tuveri from the Tampere University of Technology in Finland and Alejandro Cabrera Aldaya from the Universidad Tecnologica de la Habana CUJAE in Cuba. An advisory (http://seclists.org/oss-sec/2018/q4/123) was made to the OSS-Sec mailing list and their research has been submitted as a paper titled "Port Contention for Fun and Profit" as an IACR eprint (http://eprint.iacr.org/), which is currently awaiting moderation before it's released.
In an email with the researchers, Tuveri explained to BleepingComputer that port contention was used to measure how long it took OpenSSL to perform an operation. Using these measurements, the researchers were able to work backward to recover a private key.
"Shortly and simplifying, with SMT and 2 threads per core, a process running on one thread will have its own instructions and data but will share some hardware resources with a process running on the colocated thread.
Instructions will be decoded independently in simpler microoperations and pipelined in the CPU to the corresponding Execution Units. (Execution Units are the actual silicon areas that are specialized to handle specific operations: e.g., there are a few EU dedicated to integer additions/subtraction, separate ones for integer multiplication, other for floating point arithmetic, etc.) Every core has a complete set of EUs to support the whole instruction set, and threads on the same core share access to the EU's. EUs are grouped together in bundles each accessible through a port: microops from the two threads are issued to the available ports, and another microcomponent, the core scheduler, optimizes for fairness and performance when the same microop can be issued to different equivalent EUs behind different ports.
These ports are the object of the discussed port contention. Let's, for example, suppose port 5 is used by a victim process during a particular crypto operation: while the victim process is not using port 5, the spy process running on the other thread will have undelayed access to repeatedly execute on port 5; as soon as the victim process issues an operation on port 5, the scheduler will delay ops from the spy process to ensure fairness. The spy process can thus measure the delay in the execution of its operations for port 5, and determine when the victim process is using the same port.
This is the signal that can then be processed to ultimately recover a private key." - stated Tuveri.
To make it easier to understand the vulnerability in non-technical terms, Tuveri shared with us how Billy Brumley explained the attack to his daughter.
"You have a bag of jelly beans. I have a bag of jelly beans. We're pouring them into the same funnel. I can't see you or your jelly beans. But the rate at which I can pour my jelly beans depends on the rate you're pouring your jelly beans. If your rate depends on a secret, I can learn that secret by timing how fast my jelly beans are going into the funnel.
The jelly beans are instructions. The broad funnel part is the pipeline, and the narrow part an execution port. We are sharing the same funnel because of Simultaneous Multi-Threading (SMT)."
While the researchers have only tested this vulnerability against Intel Skylake and KabyLake processors, they also expect it to work on AMD Ryzen processors.
"We verified it on Intel Skylake and Kaby Lake, but just because we did not have access to different machines with SMT," Tuveri told BleepingComputer. "We expect it to work also on AMD Ryzen, but left this to future work."
The researchers shared a proof-of-concept (http://github.com/bbbrumley/portsmash) exploit that only targets OpenSSL. The team chose to target OpenSSL because they are familiar with the code base and because it is so widely used, but that the "PortSmash technique is not tied to a particular software."
Therefore, it is only a matter of time until diligent researchers and attackers port the PoC to steal information from other applications.
Fixes for this attack have already been added to OpenSSL 1.1.1 (http://www.openssl.org/blog/blog/2018/09/11/release111/) and for those who need an older version, patches are available (http://github.com/openssl/openssl/commit/aab7c770353b1dc4ba045938c8fb446dd1c4531e#diff-40a9b7f560ef4410b988fafff6e79928) for versions >= 1.1.0i.
Protecting yourself from the PortSmash vulnerability
The only way to mitigate this attack is to disable SMT/Hyper-threading on a computer, which OpenBSD has already done by default since this summer when another timing attack was released called TLBleed.
"It's recommended disabling SMT/Hyper-threading as a countermeasure. OpenBSD, for example, already disables it by default since this summer."
Intel has already removed hyper-threading from their new 9th generation gaming CPUs in order to offer hardware protection (http://www.windows10newsinfo.com/smf/index.php/topic,35705.0.html) from Meltdown v3 and the L1 Terminal Fault vulnerabilities. As most games do not support hyper-threading, removing it does not have much effect on the computer's performance when gaming.
Hyper-threading, though, is not going away as many organizations have invested heavily in supported hardware to provide better performance for their enterprise applications. Removing hyper-threading altogether from these environments would be too expensive of an option.
source (http://www.bleepingcomputer.com/news/security/new-portsmash-hyper-threading-cpu-vuln-can-steal-decryption-keys/)