Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

[thecoolnessrune]

https://www.intel.com/content/www/us/en/architecture-and-technology/l1tf.html

New one, I think this is related to the HT issue. This one only has a noticeable perf hit if you are running virtualized guests that you can't guarantee have been patched.

That's a pretty big problem for a lot of businesses managing their own infrastructure and for MSPs managing other customer's infrastructure. A very large number of systems out there are running without mitigations, and will be for some time.

 

[jpiniero]

That's a pretty big problem for a lot of businesses managing their own infrastructure and for MSPs managing other customer's infrastructure. A very large number of systems out there are running without mitigations, and will be for some time.

Just think of it as an excuse to upgrade to Rome Cascade Lake!

 

[coercitiv]

https://foreshadowattack.eu/

Foreshadow is a speculative execution attack on Intel processors which allows an attacker to steal sensitive information stored inside personal computers or third party clouds. Foreshadow has two versions, the original attack designed to extract data from SGX enclaves and a Next-Generation version which affects Virtual Machines (VMs), hypervisors (VMM), operating system (OS) kernel memory, and System Management Mode (SMM) memory.

While it was previously believed that SGX is resilient to speculative execution attacks (such as Meltdown and Spectre), Foreshadow demonstrates how speculative execution can be exploited for reading the contents of SGX-protected memory as well as extracting the machine’s private attestation key.

It's like they're being discovered faster than they can be disclosed, and by multiple teams as well.

The cherry on top:

The KU Leuven authors discovered the vulnerability, independently developed the attack, and first notified Intel on January 3, 2018. Their work was done independently from and concurrently to other recent x86 speculative execution vulnerabilities, notably Meltdown and Spectre.

The authors from Technion, University of Michigan, the University of Adelaide and CSIRO's Data61 independently discovered and reported the vulnerability and associated attack to Intel during the embargo period on January 23, 2018.

 

[coercitiv]

And an update from AMD:

As in the case with Meltdown, we believe our processors are not susceptible to the new speculative execution attack variants called Foreshadow or Foreshadow-NG due to our hardware paging architecture protections. We are advising customers running AMD EPYC™ processors in their datacenters, including in virtualized environments, to not implement Foreshadow-related software mitigations for their AMD platforms.

 

[Mopetar]

I know AMD would know best, but I’d want slightly more definitive language than “we believe”. Hopefully they did some extensive testing because it would absolutely blow up in their faces if they turned out to be vulnerable.

 

[moinmoin]

Not sure what's new about breaking SGX, it already has been broken into multiple times.

I know AMD would know best, but I’d want slightly more definitive language than “we believe”. Hopefully they did some extensive testing because it would absolutely blow up in their faces if they turned out to be vulnerable.

The reason why AMD "believes" this is that AMD (unlike Intel) checks for and prevents user to kernel data escalation which is why they aren't affected by e.g. Meltdown. Foreshadow also depends on such a privilege escalation to work (or rather, on a data separation by privilege to effectively not exist in hardware).

AMD uses "we believe" as there is no such thing as 100% safe. There may still be AMD specific attacks that use parts of this exploit, however unlikely.

 

[maddie]

Read the Intel info on their site. Are they actually suggesting, without saying it outright, that you should disable HT?

https://software.intel.com/security-software-guidance/software-guidance/l1-terminal-fault
"With the microcode update, the Intel SGX attestation will indicate whether hyperthreading has been enabled by the BIOS. When hyperthreading is disabled or not supported, the microcode update fully mitigates L1TF and E2E for Intel SGX. Intel SGX does not require changes to OS paging structures or VMM behavior to achieve this protection.

When hyperthreading is enabled, the possibility of L1TF or E2E attacks from the sibling logical processor still exists before the enclave secret in L1 data cache is flushed or cleared. The entity verifying the attestation might reject attestations from a hyperthreading-enabled system if it deems the risk of potential L1TF or E2E attacks from the sibling logical processor as not acceptable."

 

[french toast]

Put it this way, if intel doesn't fix these vulnerabilities by cooperlake they will be screwed.
I am optimistic cascadelake has this SMT vulnerability fixed.

 

[PingSpike]

Read the Intel info on their site. Are they actually suggesting, without saying it outright, that you should disable HT?

Kind of meshes up with the OpenBSD developers choosing to disable hyperthreading.

 

[wahdangun]

Kind of meshes up with the OpenBSD developers choosing to disable hyperthreading.

Since it was BSD, I'm expecting no less from that.

 

[thecoolnessrune]

Just think of it as an excuse to upgrade to Rome Cascade Lake!

We were just working with a client yesterday who's rebuilding an old Dell R710. It would be a nice pipe dream to get people to upgrade when it's needed, but we can't even get people to upgrade when it's already needed Gotta wait for those fires to burn.

 

[teejee]

Read the Intel info on their site. Are they actually suggesting, without saying it outright, that you should disable HT?

https://software.intel.com/security-software-guidance/software-guidance/l1-terminal-fault
"With the microcode update, the Intel SGX attestation will indicate whether hyperthreading has been enabled by the BIOS. When hyperthreading is disabled or not supported, the microcode update fully mitigates L1TF and E2E for Intel SGX. Intel SGX does not require changes to OS paging structures or VMM behavior to achieve this protection.

When hyperthreading is enabled, the possibility of L1TF or E2E attacks from the sibling logical processor still exists before the enclave secret in L1 data cache is flushed or cleared. The entity verifying the attestation might reject attestations from a hyperthreading-enabled system if it deems the risk of potential L1TF or E2E attacks from the sibling logical processor as not acceptable."

Better info here:

https://www.redhat.com/en/blog/understanding-l1-terminal-fault-aka-foreshadow-what-you-need-know

In VM cases where you might have two different VM's on the same core you should disable HT.

 

[dualsmp]

Read the Intel info on their site. Are they actually suggesting, without saying it outright, that you should disable HT?

https://software.intel.com/security-software-guidance/software-guidance/l1-terminal-fault
"With the microcode update, the Intel SGX attestation will indicate whether hyperthreading has been enabled by the BIOS. When hyperthreading is disabled or not supported, the microcode update fully mitigates L1TF and E2E for Intel SGX. Intel SGX does not require changes to OS paging structures or VMM behavior to achieve this protection.

When hyperthreading is enabled, the possibility of L1TF or E2E attacks from the sibling logical processor still exists before the enclave secret in L1 data cache is flushed or cleared. The entity verifying the attestation might reject attestations from a hyperthreading-enabled system if it deems the risk of potential L1TF or E2E attacks from the sibling logical processor as not acceptable."

OpenBSD suggests the SGX flaw (CVE-2018-3615) is the least problematic and the other two vulnerabilities are serious (CVE-2018-3620 and CVE-2018-3646).

Mailing list post:
https://marc.info/?l=openbsd-tech&m=153431475429367&w=2

Theo de Raadt criticizes the press for focusing on SGX, and seems to suggest HT (aka SMT) should be disabled for all three CVE's.

There is more here:
OpenBSD chief slams Intel, says more CPU flaws likely to be found

https://www.itwire.com/security/84056-openbsd-chief-says-more-intel-cpu-flaws-likely-to-be-found.html

from article:
"CVE-2018-3620 and CVE-2018-3646 are huge, and affect everyone with an OS which wasn't already paranoid."
...
"The other two flaws affect virtual machines, hypervisors, operating system kernel memory, and system management mode memory."

 

[ub4ty]

OpenBSD suggests the SGX flaw (CVE-2018-3615) is the least problematic and the other two vulnerabilities are serious (CVE-2018-3620 and CVE-2018-3646).

Mailing list post:
https://marc.info/?l=openbsd-tech&m=153431475429367&w=2

Theo de Raadt criticizes the press for using for focusing on SGX, and seems to suggest HT (aka SMT) should be disabled for all three CVE's.

There is more here:
OpenBSD chief slams Intel, says more CPU flaws likely to be found

https://www.itwire.com/security/84056-openbsd-chief-says-more-intel-cpu-flaws-likely-to-be-found.html

from article:
"CVE-2018-3620 and CVE-2018-3646 are huge, and affect everyone with an OS which wasn't already paranoid."
...
"The other two flaws affect virtual machines, hypervisors, operating system kernel memory, and system management mode memory."

What a nightmare this is becoming.
What I'd more importantly like fully detailed is what was the motivation behind intel's approach vs AMD's?
I don't think its a coincidence that Intel's approach leads to better performance while putting security secondary checked post-execution.
Since the start of this circus it seemed clear intel was taking shortcuts to improve performance over security in multiple areas.

Has anyone done an in-depth write-up to support such a theory?

 

[jpiniero]

What I'd more importantly like fully detailed is what was the motivation behind intel's approach vs AMD's?

There's always the NSA forced them theory.

 

[DaveSimmons]

Since the start of this circus it seemed clear intel was taking shortcuts to improve performance over security in multiple areas.

Sure, with 20/20 hindsight. At the time, before someone came up with a practical exploit, it would have seemed perfectly reasonable to get a speed boost by skipping extra checks on accesses that would be "harmless" because there were no changes to the directly observable state.

If skipping the checks increased speed and was (as far as anyone knew) harmless, then why wouldn't you make that optimization?

I'm curious whether anyone can point to any pre-Spectre statements from AMD saying they skipped optimizations like this intentionally, for better security.

 

[moinmoin]

Mailing list post:
https://marc.info/?l=openbsd-tech&m=153431475429367&w=2

"We believe Intel cpus do almost no security checks up-front, but defer checks until instruction retire. As a result we believe similar issues will be coming in the future."
Ugh...

Heise.de previously in May claimed that eight unpublished "next gen" variations on Spectre are coming, according to them three of them are published now, five to go.

 

[naukkis]

If skipping the checks increased speed and was (as far as anyone knew) harmless, then why wouldn't you make that optimization?

I'm curious whether anyone can point to any pre-Spectre statements from AMD saying they skipped optimizations like this intentionally, for better security.

Because it's a direct fault of MMU, MMU by definitions should only update TLB and bring data usable after privileges are checked, it's a first rule for MMU to separate user and kernel memory. It's a very high risk to implement as cpu isn't behaving how it should so somebody could say that cpu is faulty and need replaced. I don't know how Intel is still getting free of charge by that.

Meltdown should not exists, it's way too simple exploit. But as it works it's almost guaranteed that many, many more exploits will come after that, good luck for Intel to trying fix all of them.

 

[coercitiv]

I'm curious whether anyone can point to any pre-Spectre statements from AMD saying they skipped optimizations like this intentionally, for better security.

Nah, they skipped them intentionally for lower performance .

 

[DaveSimmons]

Because it's a direct fault of MMU, MMU by definitions should only update TLB and bring data usable after privileges are checked, it's a first rule for MMU to separate user and kernel memory. It's a very high risk to implement as cpu isn't behaving how it should so somebody could say that cpu is faulty and need replaced. I don't know how Intel is still getting free of charge by that.

Meltdown should not exists, it's way too simple exploit. But as it works it's almost guaranteed that many, many more exploits will come after that, good luck for Intel to trying fix all of them.

"It's way too simple to exploit" yet it took decades to happen? Again, hindsight is 20-20.

No, side channel exploits are ways to leak information when security is working properly.

You can look at wear patterns on keypads to guess passwords. Recall all keypads?

You can bounce a laser off windows to record audio. Recall all windows?

There are side channel exploits using RFI leakage from the CPU, audio from typing, etc.

 

[WelshBloke]

"It's way too simple to exploit" yet it took decades to happen? Again, hindsight is 20-20.

No, side channel exploits are ways to leak information when security is working properly.

You can look at wear patterns on keypads to guess passwords. Recall all keypads?

You can bounce a laser off windows to record audio. Recall all windows?

There are side channel exploits using RFI leakage from the CPU, audio from typing, etc.

Now I'll freely admit that I don't understand all this but isn't this mostly to due with Intel ignoring the "rules" rather than unavoidable things like wear on keyboards?

 

[DaveSimmons]

Now I'll freely admit that I don't understand all this but isn't this mostly to due with Intel ignoring the "rules" rather than unavoidable things like wear on keyboards?

Spectre and Meltdown aren't based on finding a bug like the eleventy million Internet Explorer, Flash and Java exploits over the years.

They're based on noticing differences in execution speed when the CPU runs code properly. It took a long, long time for anyone to figure out how to do that, and over those decades intel CPUs have run faster because of optimizing away some checks that had no effect on the end results.

Until someone figured out how to do this kind of exploit no one thought there was any reason not to optimize.

I wouldn't be surprised if AMD dodged some of the exploit variants only because they had a smaller R&D budget so couldn't optimize their speculative execution as heavily as intel.

 

[WelshBloke]

Spectre and Meltdown aren't based on finding a bug like the eleventy million Internet Explorer, Flash and Java exploits over the years.

They're based on noticing differences in execution speed when the CPU runs code properly. It took a long, long time for anyone to figure out how to do that, and over those decades intel CPUs have run faster because of optimizing away some checks that had no effect on the end results.

Until someone figured out how to do this kind of exploit no one thought there was any reason not to optimize.

I wouldn't be surprised if AMD dodged some of the exploit variants only because they had a smaller R&D budget so couldn't optimize their speculative execution as heavily as intel.

Yeah but "optimizing away some checks" is exactly the same as "cutting some corners" or "ignoring some rules".
How about if your mechanic didn't bother with tightening all your lug nuts because it was quicker? (Yay! Inappropriate car analogy!)

 

[maddie]

Spectre and Meltdown aren't based on finding a bug like the eleventy million Internet Explorer, Flash and Java exploits over the years.

They're based on noticing differences in execution speed when the CPU runs code properly. It took a long, long time for anyone to figure out how to do that, and over those decades intel CPUs have run faster because of optimizing away some checks that had no effect on the end results.

Until someone figured out how to do this kind of exploit no one thought there was any reason not to optimize.

I wouldn't be surprised if AMD dodged some of the exploit variants only because they had a smaller R&D budget so couldn't optimize their speculative execution as heavily as intel.

You are being very disingenuous. Nothing is wrong in breaking the security rules as nobody has exploited it yet.

This has to be the most bizarre defense yet.

 

[DaveSimmons]

You are being very disingenuous. Nothing is wrong in breaking the security rules as nobody has exploited it yet.

This has to be the most bizarre defense yet.

Encryption methods that were security best practices in 1980 or 1990 are unsafe now because researchers discovered ways to crack them. If you find someone using those methods now then they need to change them, but it's wrong to say using those methods showed incompetence at that time.

Speculative execution methods used by intel and AMD were best practices at the time the CPUs were designed, until years later researchers discovered ways to leak information because of them.