As it turns out the newly discovered exploit affects Kaby Lake and Skylake chops as well as AMD CPUs via a side-channel leak.
Over the last 11 months or so, computer hardware equipment knows as processors (that are also responsible for running our computers and in an increasingly greater number of smartphones as well), have had no choice but to succumb to host of vicious cyber attacks.
These attacks come bearing strange names such as the likes of,
These security exploits essentially threaten to siphon off some of the most sensitive and personal secrets that online consumers may have on their computers.
We’re talking about cryptographic keys and passwords.
The other weird thing about these security exploits is that they can go about their business right out of the silicon microarchitecture.
And they can hurt machines in ways that traditional security defenses can’t stop and/or detect.
Last Friday, security researchers managed to disclose yet another security leak which they have already shown to exist on a huge range of chips from Intel.
In fact, security researchers say that the latest security leak may also affect other chip makers.
Security researchers are calling the new attack PortSmash.
The PortSmash security exploit takes advantage of a largely overlooked side-channel which exists in Intel’s proprietary hyperthreading technology.
Intel’s proprietary implementation of the technique the community knows as simultaneous multithreading, hyperthreading actually allows the processor to reduce the amount of time it needs to carry out various parallel computing tasks.
In such computing tasks, the processor has to manage a rather large number of executions and/or calculations.
And it has to carry out all of them simultaneously.
The actual performance boost comes as a result of a total of two logical processor cores that successfully share the hardware of one (single) physical computer processor.
Now, the extra logical cores actually make it much easier for the machine to divide up large tasks into many smaller ones which the processor can complete a lot more quickly.
The problem of port contention as a side channel
Security researchers have written on a paper which is scheduled for release in the coming months in which they document how they managed to exploit the freshly discovered leak in order to alter a server which was running an OpenSSL-powered TLS server to recover an elliptic curve privacy key.
Security researchers carried out the attack on servers running Kaby Lake and SkyLake chips along with running Ubuntu as the operating system.
The attack went about its business sending just one of the two logical processor cores a steady stream of machine instructions.
All the while, the attack carefully measure the total time it took the processor to execute them.
Why did the attack measure the time?
Well, by measuring the specific timing, it allowed PortSmash to successfully deduce the exact key being currently processor in the other logical core of the very same processor.
And of course, the resource which is responsible to provide the leak is none other than port contention.
What is port contention?
Port contention is simply a phenomenon which happens when a multiple number of instructions make use of the same physical computer processor resources and also get assigned to various different ports in order to wait their completion phase.
Security researchers have indexed with vulnerability as CVE-2018-5407.
As of now, this security flaw affects personal computers pretty much with the same effectiveness as servers even though the vector which it uses to exploit the security vulnerabilities, generally speaking, favors servers rather than personal computers.
Researchers working on the vulnerability wrote in their paper that their technique could select among a good number of configurations in order to target different configurations to, then, target various different ports so that the attack is able to adapt to various different scenarios and thus offer exploiters of this vulnerability a fairly fine spatial granularity.
Researchers also wrote that in addition to that, PortSmash represented a highly portable security vulnerability.
Moreover, the prerequisites for its proper execution are fairly minimal as well.
In other words, it does not require the exploiter to have any knowledge of any machine learning techniques, eviction sets, memory cache-lines nor even general topics such as reverse engineering and all the techniques related with it.
A professor at the Tampere University of Technology based in Finland, Billy Bob Brumley, who worked on the paper as one of its authors, recently said in an email that he expected the computer chips beyond Kaby Lake and SkyLake architectures to have similar vulnerabilities against attack codes with slight modifications.
He said that the community strongly suspected AMD Ryzen architectures that feature SMT to have this vulnerability however they did leave the associated work for a future project.
Billy Bob also wrote that the real reason why researchers had not studied the AMD Ryzen till now is that they did not have the proper hardware to test exploit on at the current moment in time.
Hence, all that his research group could do was to wait for a bit.
Brumley also mentioned that the most plausible real-world scenario for someone to maliciously exploit the newly discovered security vulnerability lied in the so-called infrastructure as a service environments.
In such environments, a given cloud service provider hosted all the trappings that are associated with an on-premises data center.
This would include network hardware along with storage and server hardware along with the hypervisor and/or virtualization layer.
Brumley also wrote that from a personal perspective, he felt that remote login scenarios represented the biggest targeted threat of them all.
As an example, Brumley mentioned that a malicious user with proper credentials could easily log in via the SSH protocol and could compile the related exploit code and then even run it to extract various types of information from all the other processes which may be running in parallel.
He also mentioned that the exploit was usually written in x64 assembly code which, most of the time, ran locally on a given vulnerable machine.