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

Page 77 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

moinmoin

Diamond Member
Jun 1, 2017
4,933
7,618
136
From the article:

“In this particular case, once we had identified the issue with the incorrect emulation of the trap flag, our hypervisor team was able to test and deploy a fix.”

Researchers have since been able to fix this evasion problem for any malware sample by deploying this technique.


So it's not a vulnerability in the CPU but a behavior that hypervisors didn't replicate before, thus allowing applications to use this to detect whether they are in a VM or not. The question now is if that "Trap Flag" is completely undocumented. If so, all the blame still goes to Intel. (No mention of AMD unfortunately. If AMD CPUs don't show that behavior it's indeed completely undocumented.)
 

moinmoin

Diamond Member
Jun 1, 2017
4,933
7,618
136
What's reported seems to be purely bad Windows driver coding, though the fact that the black box PSP even allows that to happen is very worrying. This should be easily exploitable through adapted Linux drivers (or any other open source system) then. I can only hope PSP gets more scrutinized now.
 
  • Like
Reactions: coercitiv

coercitiv

Diamond Member
Jan 24, 2014
6,150
11,670
136
Seems the news is a little late. AMD PSP driver 5.17.0.0 was an optional windows update around a month ago. At least now I know why.
All security related news is a little late when vulnerability reasearch is disclosed responsibly and the vendor takes it seriously.
 

WilliamM2

Platinum Member
Jun 14, 2012
2,353
463
126
All security related news is a little late when vulnerability reasearch is disclosed responsibly and the vendor takes it seriously.

I agree, and like I said, at least now I know what it was for, so I installed it. Thanks for that, I always ignore driver updates if I'm not having issues. Driver date is 6/11/2021, so they have known for a while.

The real question, is why was it an "optional" update? Security issues should be automatic updates.
 

tamz_msc

Diamond Member
Jan 5, 2017
3,708
3,553
136
Looks like researchers have finally begun to put AMD CPUs under increased scrutiny. The same researchers who discovered Spectre and Meltdown on Intel have discovered similar side channel vulnerabilities on architectures up to Zen 2.


Modern operating systems fundamentally rely on the strict isolation of user applications from the kernel. This isolation is enforced by the hardware. On Intel CPUs, this isolation has been shown to be imperfect, for instance, with the prefetch side-channel. With Meltdown, it was even completely circumvented. Both the prefetch side channel and Meltdown have been mitigated with the same software patch on Intel. As AMD is believed to be not vulnerable to these attacks, this software patch is not active by default on AMD CPUs.
In this paper, we show that the isolation on AMD CPUs suffers from the same type of side-channel leakage. We discover timing and power variations of the prefetch instruction that can be observed from unprivileged user space. In contrast to previous work on prefetch attacks on Intel, we show that the prefetch instruction on AMD leaks even more information. We demonstrate the significance of this side channel with multiple case studies in real-world scenarios. We demonstrate the first microarchitectural break of (fine-grained) KASLR on AMD CPUs. We monitor kernel activity, e.g., if audio is played over Bluetooth, and establish a covert channel. Finally, we even leak kernel memory with 52.85 B/s with simple Spectre gadgets in the Linux kernel. We show that stronger page table isolation should be activated on AMD CPUs by default to mitigate our presented attacks successfully.

This is in addition to the vulnerability in SEV discovered a couple of months ago. This is a more severe bug IMO as it affects one of the main features of EPYC, and all Zen generations seem to be affected.


AMD Secure Encrypted Virtualization (SEV) offers protection mechanisms for virtual machines in untrusted environments through memory and register encryption. To separate security-sensitive operations from software executing on the main x86 cores, SEV leverages the AMD Secure Processor (AMD-SP). This paper introduces a new approach to attack SEV-protected virtual machines (VMs) by targeting the AMD-SP. We present a voltage glitching attack that allows an attacker to execute custom payloads on the AMD-SPs of all microarchitectures that support SEV currently on the market (Zen 1, Zen 2, and Zen 3). The presented methods allow us to deploy a custom SEV firmware on the AMD-SP, which enables an adversary to decrypt a VM's memory. Furthermore, using our approach, we can extract endorsement keys of SEV-enabled CPUs, which allows us to fake attestation reports or to pose as a valid target for VM migration without requiring physical access to the target host. Moreover, we reverse-engineered the Versioned Chip Endorsement Key (VCEK) mechanism introduced with SEV Secure Nested Paging (SEV-SNP). The VCEK binds the endorsement keys to the firmware version of TCB components relevant for SEV. Building on the ability to extract the endorsement keys, we show how to derive valid VCEKs for arbitrary firmware versions. With our findings, we prove that SEV cannot adequately protect confidential data in cloud environments from insider attackers, such as rogue administrators, on currently available CPUs.

What's interesting to note is that the vulnerabilities have been disclosed to AMD quite a while ago, but no official acknowledgement from them yet, to the best of my knowledge.
 
  • Like
Reactions: ryan20fun

Stuka87

Diamond Member
Dec 10, 2010
6,240
2,559
136
What's interesting to note is that the vulnerabilities have been disclosed to AMD quite a while ago, but no official acknowledgement from them yet, to the best of my knowledge.

It would be a bad idea for them to publicly acknowledge a bug before it was made public. Even with the original spectre/meltdown issues, Intel, AMD, and MS knew about them like six months before the puplic did, so they had a head start on finding a resolution.

These types of bugs are never quick fixes.
 

moinmoin

Diamond Member
Jun 1, 2017
4,933
7,618
136
That one "voltage glitching attack" eh? I don't want to downplay it and I'm sure AMD is looking at preventing that in future products anyway. But physical access to power (in a cloud datacenter no less) in a way that such an attack can be executed without destroying hardware on the way seems like some orders lower on the feasibility range than other security holes so far.
 
  • Like
Reactions: JimKiler

tamz_msc

Diamond Member
Jan 5, 2017
3,708
3,553
136
That one "voltage glitching attack" eh? I don't want to downplay it and I'm sure AMD is looking at preventing that in future products anyway. But physical access to power (in a cloud datacenter no less) in a way that such an attack can be executed without destroying hardware on the way seems like some orders lower on the feasibility range than other security holes so far.
In an email to The Register Robert Buhren, one of the paper’s co-authors, challenged AMD’s claim that physical access is required to carry out the attack.


“Our attack allows to extract keys from AMD CPUs that can be used to attack VMs running on *other* CPUs,” explained Buhren. “There is no relation between the CPU that we extracted the keys from and the CPU of the target system except for that the CPUs are from the same AMD microarchitecture, i.e, both CPUs are Epyc Milan CPUs ( Zen 3 ).


“A malicious administrator can, for example, buy a AMD Epyc CPU online, extract the keys and then use these keys to target SEV systems in a data-center without needing to physically access the target systems. In our paper we specifically describe an attack scenario that allows an attacker to decrypt a SEV protected VM’s memory without physical access to the system hosting the VM.”





From the rules:
"your post must contain your own original written content and cannot consist solely of another's content, be it a quote, image, or link"

You need to post some of your own commentary to the link and quotes you are posting.

esquared
Anandtech Forum Director
 
Last edited by a moderator:

DrMrLordX

Lifer
Apr 27, 2000
21,582
10,784
136
Looks like researchers have finally begun to put AMD CPUs under increased scrutiny. The same researchers who discovered Spectre and Meltdown on Intel have discovered similar side channel vulnerabilities on architectures up to Zen 2.

That's odd. AMD was already vulnerable to Spectre, partially.
 

beginner99

Diamond Member
Jun 2, 2009
5,208
1,580
136
Looks like researchers have finally begun to put AMD CPUs under increased scrutiny. The same researchers who discovered Spectre and Meltdown on Intel have discovered similar side channel vulnerabilities on architectures up to Zen 2.

I mean for home user even meltdown and spectre were completely overblown especially given the resulting performance penalties and after reducing JavaScript timer accuracy. it's a concern with cloud services. But if your data is that sensitive, you will run dedicated instances anyway again making less important than implied.
 
  • Like
Reactions: ryan20fun

tamz_msc

Diamond Member
Jan 5, 2017
3,708
3,553
136
It would be a bad idea for them to publicly acknowledge a bug before it was made public. Even with the original spectre/meltdown issues, Intel, AMD, and MS knew about them like six months before the puplic did, so they had a head start on finding a resolution.

These types of bugs are never quick fixes.
The SEV vulnerability has been public for two months now.
 

moinmoin

Diamond Member
Jun 1, 2017
4,933
7,618
136
Hm, reading more into it these are actually not vulnerabilities in SEV, but in the PSP. And that's not better but much much worse. The voltage glitching attack isn't used to defeat SEV and extract keys from there, but to glitch the PSP and extract fundamental keys and seeds from there. And those are shared across all CPUs of the same family apparently. So they can be used to access the PSP on any system, thus allowing access to all encrypted SEV processes as the PSP has to store the keys to decrypt any encrypted data. With PSP being the central arbiter for anything security its keys being leaked breaks any security feature that builds upon it.

Thanks @tamz_msc for keeping referring to this, all the talk about SEV in the paper and in the press only helped obfuscating the real issue there imo.
 

moinmoin

Diamond Member
Jun 1, 2017
4,933
7,618
136
The SEV exploit is separate. I wasn't talking about that.
Not the PSP exploit, ok.
Do any of the old Spectre mitigations for AMD CPUs prevent these attacks from working?
So you are referring to the AMD Prefetch attacks. As the paper states the existing KPTI (deemed not necessary for AMD CPUs back then) mitigates all three attacks mentioned in the paper.
 

moinmoin

Diamond Member
Jun 1, 2017
4,933
7,618
136
So, basically, no, the old AMD Spectre mitigations don't stop the prefetch attacks.
Correct. Though there weren't AMD specific Spectre mitigations to begin with, and those that were recommended to be applied for AMD CPUs as well were the ones of general nature, namely Spectre V1 which concerns leaks between processes within the same protection ring, something x86 was previously never designed to protect against to begin with. And KPTI is technically no mitigation specific to Spectre/Meltdown or Intel but started as a defence in depth effort.
 

SamMaster

Member
Jun 26, 2010
148
75
101
Looks like another vulnerability is to be added, affects Intel's SGX. There are patches already out for it by Intel and Microsoft, but those with other platforms are affected.

https://www.tomshardware.com/news/smashex-attack-targets-intel-sgx

But the team that discovered SmashEx said this attack is novel for a few reasons. "SmashEx is the first attack that demonstrates the exception handling attack vector on Intel SGX," it said. "SmashEx does not assume any side channels or pre-existing memory safety bugs in the enclaved application code. [...] Unlike side-channel attacks on SGX enclaves such as Spectre and controlled-channel attacks, SmashEx can directly corrupt the enclave private data and break the enclave integrity."

The researchers confirmed that SmashEx can be used against seven other runtimes from Arm, Google, and Apache, among others.
 
  • Wow
Reactions: moinmoin

amd6502

Senior member
Apr 21, 2017
971
360
136
I think Spec exe is very often hard to exploit. The real problem is the PSP and its related components. This is the sort of reason why the customer absolutely should have the option to disable the PSP in a failsafe way.

As for spec exe, there ought to be a new instruction or internal flag that can be set to force speculative execution. And even privileged instructions for metrics maybe, that can identify fishy code that has recently executed.

As for the Radeon drivers, this doesn't seem to limited to just windows. It seems to exist in linux too.
 

nicalandia

Diamond Member
Jan 10, 2019
3,330
5,281
136
The gift that keeps on giving... Can anyone check this out?


"The vulnerability—present in Pentium, Celeron, and Atom CPUs on the Apollo Lake, Gemini Lake, and Gemini Lake Refresh platforms—allows skilled hackers with possession of an affected chip to run it in debug and testing modes used by firmware developers. Intel and other chipmakers go to great lengths to prevent such access by unauthorized people. "

 
  • Like
Reactions: lightmanek

Stuka87

Diamond Member
Dec 10, 2010
6,240
2,559
136
The gift that keeps on giving... Can anyone check this out?


"The vulnerability—present in Pentium, Celeron, and Atom CPUs on the Apollo Lake, Gemini Lake, and Gemini Lake Refresh platforms—allows skilled hackers with possession of an affected chip to run it in debug and testing modes used by firmware developers. Intel and other chipmakers go to great lengths to prevent such access by unauthorized people. "


I read about it this morning. As the ars article states, the most common "use" of this would be to get around encryption on lost/stolen laptops. My work laptop for instance has the drive encrypted with bitlocker. Which in itself is very secure. Unless the person in possession of it has the ability to gain access to the master key via the security hole.

So its not something the average user needs to worry about. But it could be a big deal for companies that have employee laptops stolen with what could be very important data.
 
  • Like
Reactions: lightmanek