Tag Archives: private keys

PortSmash Vulnerability: What you need to know

Security researchers have released details of a new side channel attack known as “PortSmash” that can be used to steal information from processes running inside a computer systems CPU (defined)) when Intel Hyperthreading (HT)(defined here and here) is enabled. Their proof of concept allowed them to steal a private decryption from a thread running in the same core as their exploit. This thread belonged to an OpenSSL process.

How severe is this vulnerability?
It has been designated as CVE-2018-5407 and assigned a base score of 4.8 (medium severity) on the CVSS v3 scale (defined) with a high attack complexity and with only low privileges required. The attack cannot be exploited remotely. An attacker must have been able to compromise your system via another means most likely a phishing email (social engineering)(phishing: defined; social engineering: defined), accidentally clicking a malicious link or a drive by download (defined). The attacker will also still need to have their code running within the same core as the data/code they wish to obtain. Similar to Spectre; multi-tenant cloud environments are more at risk.

Red Hat’s security advisory states “In order to exploit this flaw, the attacker needs to run a malicious process on the same core of the processor as the victim process”. PortSmash is fundamentally different from Meltdown and Spectre vulnerabilities; it does not rely on speculative execution.

Collin Percival, a Computer Scientist summed up the attack as follows:

“I’ve been getting a few questions about the recent “PortSmash” vulnerability announcement. Short answer: This is not something you need to worry about. If your code is vulnerable to it, you were already vulnerable to other (easier) attacks.

He advises that users don’t need to worry about it and states: “the defence against microarchitectural side channel attacks from 2005: Make sure that the cryptographic key you’re using does not affect the sequence of instructions or memory accesses performed by your code”.

How does this vulnerability work?
When a thread (defined) is carrying out some work it has its own instructions (what to do) and data (the objects to work on) but it will share some of its hardware resources with another process operating on a collocated thread.

The attackers can obtain information about the decryption key by analysing how fast the (process) thread within the CPU is operating with particular assembly language (defined) instructions and uses that information to work backwards (reverse engineering) on what possible data was used as the input to achieve this data now being processed. In this case the data is a private decryption key (defined).

Explained another way: This attack uses instruction timing (how long it takes to process) based on port contention. Each core of a CPU has physical regions known as ports which carry out the necessary calculations. If two or more threads are processing at the same they may have to wait on each other to use those regions of the CPU.

PortSmash seeks to monopolise a port which is being shared with a thread with information the attack wishes to obtain. They can measure the time taken between instructions of the attackers thread and the legitimate thread (thus determining how long the legitimate thread spend processing). This will help to obtain the data being processed over a long period of time

PortSmash is a side channel attack meaning that the attacker doesn’t immediately find out the protected/secret value immediately; instead the attack seeks out information from the other thread running within the CPU for information on the secret value being processed.

The proof of concept code targeted OpenSSL but is not limited to just that software. OpenSSL was targeted due to the researcher’s familiarity with the OpenSSL code.

What CPUs are affected by this vulnerability?
The researchers verified that this vulnerability is present on Intel Skylake CPUs (6th generation Core models e.g. i7 6700K). However any Intel CPU which implements HT is likely to have this vulnerability. Intel’s Nehalem architecture first introduced HT in 2008. The researchers believe AMD Ryzen CPUs may be affected but did not confirm this.

How can I protect myself from this vulnerability?
OpenSSL have added a fix to version 1.1.1 and older versions greater than version 1.1.0i (Source)

However the only true means of mitigating this vulnerability for all software is to disable Intel’s HT. The operating system distribution OpenBSD has done so since June this year. Similarly Intel within their new 9th generation Core CPUs disabled HT to enable hardware protections against the Meltdown, Spectre and L1 Terminal Fault vulnerabilities. They did so to their gaming focused CPUs since many games don’t leverage HT and thus don’t suffer a performance penalty from not using it. It doesn’t appear that HT was removed for security concerns since the Core i9 9900K still features it.

Since corporate organizations may have invested in software that uses HT; they should only consider turning it off if continuing to use it places them at a high risk of exploitation and would place them outside of what they consider an acceptable risk. They will then need to consider the performance/security trade-off of doing so.

If you use Intel HT I would recommend testing your own software with this feature turned off to tell if it has too much of a performance penalty for your particular use cases. From researching this it is not a straightforward answer of turning it off and definitely not experiencing any slowdown; it may or may not happen depending on how you use your system and the software you use.

I have provided links to definitions of HT above and some references below which may assist you in making a decision to disable or leave it enabled. That research also pointed out that if you wish to disable HT; please do so from the BIOS (defined) of your computing system since it will have a blanket disablement across all software and your operating system. A software disablement can work but disabling via the BIOS leaves less room for error. Please refer to your system manufacturer or motherboard user guide for the steps to enter the BIOS of the system and disable this feature.

As more details of this vulnerability emerge I will consider disabling this feature on my water cooled Intel Core i9 7980XE CPU. Windows detects it with 36 logical cores; with HT disabled it will “drop” to 18 physical cores. I’ll need to evaluate the performance impact (if any) for my particular use cases. Given the attacker will need to already have compromised my system and the attack is of high complexity; it’s less likely I will need to disable HT. My existing security controls are more than enough to mitigate this risk; but your system, configuration and risk appetite may be different.

Thank you.

==============

References:

Why You Disable Hyper-Threading or NOT, and How to Know the Difference

https://bitsum.com/tips-and-tweaks/why-you-should-not-disable-hyper-threading-or-why-you-should/

Nehalem – Everything You Need to Know about Intel’s New Architecture

Source: https://www.anandtech.com/show/2594/8

 

Performance-impact of Hyper-Threading:

https://superuser.com/questions/1166529/performance-impact-of-hyper-threading

 

Is Hyper-Threading a Fundamental Security Risk?

https://www.extremetech.com/computing/276138-is-hyper-threading-a-fundamental-security-risk

Why does disabling hyperthreading supposedly give better gaming performance? (This is again a gaming focused discussion but would be relevant for software that does not use HT):

https://www.reddit.com/r/pcgaming/comments/2hti6m/why_does_disabling_hyperthreading_supposedly_give/

 

Why on earth would you disable Hyperthreading? (This is a more gaming focused discussion but would be relevant for software that does not use HT. Please ignore the advert spam posts for software named CPUCores, it’s confirmedsnake oil”):

https://steamcommunity.com/app/384300/discussions/0/530646080862961117/

==============

Infineon TPM Chips Patched Against Disclosed Vulnerability

With the release of Microsoft’s security updates last week; Infineon published a security advisory relating to a vulnerability discovered by security researchers in 2012.

Why should this vulnerability be considered important?
The vulnerable hardware is mostly to be found within corporate computers from manufacturers such as HP, Fujitsu and Lenovo. Google Chromebooks, routers and some Internet of Things (IoT)(defined). The vulnerability allows an attacker to determine a private (defined) encryption key when it has been generated by a vulnerable TPM (Trusted Platform Module) using only the public key (defined). Once the private key has been obtained it can be used by an attacker to decrypt the contents of a Microsoft BitLocker encrypted hard drive, to digitally sign fake software releases, to sign malware (making it appear more legitimate) as well impersonating the legitimate owner of the private key.

This vulnerability also affects cryptographic smart cards, security tokens and other secure hardware chips manufactured by Infineon. An estimate 760k devices are thought to be vulnerable while the true number could be up to three times that amount.

While the researchers were able to verify an attacker could derive the private key from 1024 and 2048 but public key, they were unable to do so for 4096 bit key since “a 4096-bit RSA key is not practically factorizable now, but “may become so, if the attack is improved.” For 1024 and 2048 bit keys, the factorisation can be easily parallelised by x number of CPUs, reducing the time taken by x times (where x is the number of cores a CPU has) allowing completion in hour or days.

How can I protect myself from this vulnerability?
Microsoft’s advisory provides the recommended steps for systems using Windows or other Microsoft products e.g. Active Directory Certificate Services (ADCS), Active Directory Directory Services (ADDS) (among others). The updates they recommend are only a workaround for the vulnerability. The vulnerability must still be resolved by applying updates to the vulnerable TPM chips. This advice also includes clearing the TPM and re-generating the necessary keys only after applying the updates from Microsoft.

Similarly Google made available Chrome OS M60 to mitigate this vulnerability. Further links to other affected vendors are listed below:

Fujitsu

HP Customer Support

HP Enterprise Support

Lenovo

Toshiba

Thank you.

Dell Inadvertently Ships Root Certificates With System Tools

Earlier last week it was discovered that the computer manufacturer Dell had mistakenly included with a Dell Support tool (called DFS (Dell Foundation Services)) used to assist customers in a more efficient manner; a preinstalled root certificate (named eDellRoot) and a private key (defined) that was used to create that certificate. Dell’s explanation for the purpose for this certificate was described as “it was intended to provide the system service tag to Dell online support allowing us to quickly identify the computer model, making it easier and faster to service our customers.” (Source).

A certificate is a means usually provided by a Certificate Authority (defined) to determine if a TLS certificate being used by a website can be trusted.

In addition, a second certificate (named DSDTestProvider) was found to be included with another Dell tool, namely DSD (Dell System Detect) which users are prompted to install when they visit the Dell support website and click the button to detect the type of Dell product they are using.


Why Should The Inclusion Of These Certificates On My Dell Device Be Considered Important?

Since the private keys for these certificates were also bundled with them (a severe deviation from best practice) they could be used by attackers to generate fake certificates for any website of their choice which would be accepted as legitimate by affected Dell systems. The attackers using these certificates could then decrypt the secured connections to those sites using the private keys. An example of another attack in this instance is a man-in-the-middle attack (defined) that could be used against affected devices is presented in this blog post.

These certificates could also be used to digitally sign malware and make it appear legitimate. If malicious drivers were signed using these certificates they could also bypass driver signature verification within 64 bit versions of Windows.

Which Dell Systems/Devices Are Affected By These Issues?
The following systems are reported to be affected: the XPS 15, Latitude E7450, Inspirion 5548, Inspirion 5000, Inspiron 3647, and the Precision M4800.

The Dell Foundation Services certificate may also be present on laptops, desktops, two-in-ones, all-in-ones, and towers from various Dell product lines, including XPS, Vostro and Precision Tower, OptiPlex and Inspiron since it is available to download for all of those devices.

According to this post, further Dell systems are also affected. My thanks to ComputerWorld and Lucian Constantin for this information.

How Can I Protect Myself From These Issues?
First of all you can check if your Dell device is affected by this issue by visiting this website (my thanks to Graham Cluley for this link). US-CERT have also provided a website to check if your system is affected by these issues and have provided a comprehensive set of steps to resolve these security issues.

Moreover, Microsoft have updated their anti-malware tools to detect and remove these certificates. Further details are available here.

Feedback
Were you affected by this issue? If so, how did you resolve it? Were the above steps useful to you? As always if you have any questions or comments about this post or any other, please do not hesitate to contact me.

Thank you.