Monday, May 28th 2018

AMD EPYC Secure Encrypted Virtualization Not So Secure: Researchers

Secure Encrypted Virtualization (SEV) was touted as one of the killer features of AMD EPYC and Ryzen Pro series processors. It involves encryption of parts of the memory of the host machine which house virtual machines (or guests), with encryption keys stored on the processor, so the host has no scope of infiltrating or reading the contents of the guest's memory. This was designed to build trust in cloud-computing and shared hosting industries, so web-present small businesses with sensitive data could have some peace of mind and wouldn't have to spend big on dedicated hosting. A Germany-based IT security research team from Fraunhofer AISEC, thinks otherwise.

Using a technique called "SEVered," the researchers were able to use rogue host-level administrator, or malware within a hypervisor, to bypass SEV and copy decrypted information from the guest machine's memory. The exploit involves alteration of the guest machine's physical memory mappings using standard page tables, so SEV can't properly isolate and encrypt parts of the guest in the physical memory. The exploit is so brazen, that you could pull plaintext information out of compromised guests. The researchers published a paper on SEVered, along with technical details of the exploit.
Source: The Register
Add your own comment

31 Comments on AMD EPYC Secure Encrypted Virtualization Not So Secure: Researchers

#1
Assimilator
While it's great that we're finally getting real security people looking at CPUs, it's terrifying that the manufacturers themselves never did this due diligence.
Posted on Reply
#2
RejZoR
AssimilatorWhile it's great that we're finally getting real security people looking at CPUs, it's terrifying that the manufacturers themselves never did this due diligence.
I think main problem is when you design your thing, you're too confident it's designed well. About similar as to how developers are generally incapable of placing themselves on an user level when it comes to UI/UX design choices or how to design features. They always look at it from their perspective. And while you need to be an expert to design such things, that doesn't mean you're actually the best one to evaluate the design. We'll never be able to get rid of them all, but they'll have to make 2 things, either CPU's easier to patch up without buying a new one or waiting months for BIOS update that may even never come (which opens them to new attacks at the same time) or make rigorous audits with large security firms before launching products to market. But again, it'll never be possible to make it 100%.

Frankly, till now, no one really gave much concern, not even bad guys. But after Spectre and meltdown, I bet a lot of them are now focused poking CPU's. If one thing worked, chances are, something else will too. And here is the product of that.
Posted on Reply
#3
Patriot
AssimilatorWhile it's great that we're finally getting real security people looking at CPUs, it's terrifying that the manufacturers themselves never did this due diligence.
While I do like the more security focused results... this is yet another improper release... yes it's a vulnerability, that requires owning the system.
It's like everything with a catchy name and lacking a CV requires root access... heck, they even had to make a custom version of KVM for this to even work.
Posted on Reply
#4
jango_k
They are REPLACING the host hypervisor with a new one which is specifically allowed to snoop in the memory accesses. And they still need a VM on the same host to be a web server of allow other kind of memory access to the same ram as the target VM. This cannot be done in a datacenter without collusion with IT administrators from the whole chain of command.
Blaming the manufacturer because the product does not behave the same after the user flashes a new bios is unfathomable.
Even CTS Labs would not stoop so low as to report this a vulnerability.
Posted on Reply
#5
Space Lynx
Astronaut
jango_kThey are REPLACING the host hypervisor with a new one which is specifically allowed to snoop in the memory accesses. And they still need a VM on the same host to be a web server of allow other kind of memory access to the same ram as the target VM. This cannot be done in a datacenter without collusion with IT administrators from the whole chain of command.
Blaming the manufacturer because the product does not behave the same after the user flashes a new bios is unfathomable.
Even CTS Labs would not stoop so low as to report this a vulnerability.
I didn't understand half of that, but I like your style. I myself am AMD for life for gaming.
Posted on Reply
#6
TheGuruStud
jango_kThey are REPLACING the host hypervisor with a new one which is specifically allowed to snoop in the memory accesses. And they still need a VM on the same host to be a web server of allow other kind of memory access to the same ram as the target VM. This cannot be done in a datacenter without collusion with IT administrators from the whole chain of command.
Blaming the manufacturer because the product does not behave the same after the user flashes a new bios is unfathomable.
Even CTS Labs would not stoop so low as to report this a vulnerability.
I knew this was the case before I even read it. AMD has done a very solid job on Zen and everyone is looking to discredit them any way possible.
Posted on Reply
#7
theGryphon
jango_kThey are REPLACING the host hypervisor with a new one which is specifically allowed to snoop in the memory accesses. And they still need a VM on the same host to be a web server of allow other kind of memory access to the same ram as the target VM. This cannot be done in a datacenter without collusion with IT administrators from the whole chain of command.
Blaming the manufacturer because the product does not behave the same after the user flashes a new bios is unfathomable.
Even CTS Labs would not stoop so low as to report this a vulnerability.
Yeah, I read the paper, and the attack requires modification at the host.

Quoting the paper,
"As malicious HV, we used Kernel-based Virtual Machine (KVM) and modified it to execute our attack. To realize our tracking mechanism, we extended the KVM infrastructure for guest write access tracking [7] to track all kinds of accesses. We furthermore extended KVM with functionality to alter memory mappings for the extraction phase. Both features can be controlled by the attacker in the host Linux running the target VM. "

Someone explain to me, if one can do this, wouldn't they also be able to, idk, disable SEV altogether, and/or do something exponentially more evil and harmful?

Heck, an evil host can "claim" encryption and not have it, and plainly read/collect all data at the guest... am I wrong?
Posted on Reply
#8
R0H1T
AssimilatorWhile it's great that we're finally getting real security people looking at CPUs, it's terrifying that the manufacturers themselves never did this due diligence.
There's a lot that can happen between design phase & its implementation. Just look at branch prediction for example.
TheGuruStudI knew this was the case before I even read it. AMD has done a very solid job on Zen and everyone is looking to discredit them anyway possible.
While I agree with the sentiment, I do believe AMD as well as Intel need to work with 3rd party independent security research firms more to find exploits in their uarches before malicious actors or govts do, especially after GPZ et al. This is assuming they didn't place it there in the first place.
Posted on Reply
#9
progste
A new "security issue" that requires administrator priviledge, already has a cool name to go with it and was released immediately to the press without alerting the manufacturer... Sounds familiar?
Posted on Reply
#10
dwade
The damage control team is already doing work.
Posted on Reply
#11
techy1
I do not read other tech news, so please tell me - do they all copy/paste this BS ( I did not mean "copy/paste" - of course I did mean: "press release the most important and relevant news carefully evaluating and reading through to determine each information truth and factual integrity before publishing")? or is it just TPU?
Posted on Reply
#12
silentbogo
There's one more thing that looks suspicious.
Their paper is pretty much a slightly modified copycat of this one, published by members of Tangram Technologies from Shanghai back in December.

arxiv.org/ftp/arxiv/papers/1712/1712.05090.pdf

Their team lead, ZhaoHui Du, is very notable for being an Intel researcher and software engineer for almost 18 years. It's not a red flag by any means, but considering that Tangram was founded in 2017, it raises some concerns and suspicions.
Posted on Reply
#13
john_
In the not so far future....

"We then simply created a hardware adaptor that we inserted between the AMD processors and the socket. Thanks to that simple to make adaptor (if you are a multi billion company with decades of expertise) we could easily have access to the information the processor was processing"
Posted on Reply
#14
jigar2speed
Intel trying desperately to stop AMD from entering Server market by legitimately discrediting them via proxy security companies ? Meanwhile people here are arguing how bad AMD CPU security is forgetting Intel Spectre vulnerability spree hasn't ended yet.
dwadeThe damage control team is already doing work.
Ever wonder why below news wasn't published or received much of lime light ?

8 New Spectre-Class Vulnerabilities (Spectre-NG) Found in Intel CPUs

thehackernews.com/2018/05/intel-spectre-vulnerability.html
Posted on Reply
#15
Totally
Is there any form of chip level security that can withstand such an attack? I feel like this is just as moot point, maligning a front door lock because a burglar drove a bulldozer through the back of the house and had his pick of the valuables inside.
Posted on Reply
#16
Capitan Harlock
This kind of move without inform whoever is the company of the product is so lame .
Is like discovering a bad batch of tomatoes and instead of inform the seller you go to the press and saying stuff .
This don't make any sense .
Amd should take them to court because is not right at all .
Makes me wonder if someone is a shill there.
Posted on Reply
#17
ghazi
Capitan HarlockThis kind of move without inform whoever is the company of the product is so lame .
Is like discovering a bad batch of tomatoes and instead of inform the seller you go to the press and saying stuff .
This don't make any sense .
Amd should take them to court because is not right at all .
Makes me wonder if someone is a shill there.
In my eyes it's no coincidence that AMD is being targeted in this way. Exploit revealed to the press without the company being informed first, "exploit" that requires a machine to already be heavily compromised (but that's not made particularly clear in the press reports), a serious-sounding name given to the exploit to try to spread word of it and get people to remember it, and just the whole thing generally being way overhyped for what it is. And let's not mention the thing about there being another article on the same website that reports basically the same thing, but the lead author is a long-time Intel employee.

Thankfully this didn't come with a ridiculous press deck, greenscreen videos, or blatant stock manipulation attempt like the CTS Labs "exploits". If anything this looks more like an attempt to damage AMD's reputation in the data center market, rather than a short play.
Posted on Reply
#18
Imsochobo
TotallyIs there any form of chip level security that can withstand such an attack? I feel like this is just as moot point maligning a front door lock because a burglar drove a bulldozer through the back of the house.
You can disallow the user from doing what he wants?
Posted on Reply
#19
PowerPC
Fraunhofer AISEC, the people that published this paper, come more from the academic side. Their institutes are funded by the state of Germany. It could just be that some students there needed to write a paper for their final examination and just happened to have access to an EPYC CPU. Not everything needs to be a big conspiracy by Intel. Of course they are going to publish it because applied IT-security is now a normal field of research and Fraunhofer AISEC is their "Institute for Applied and Integrated Security". They have to write papers and publish them, that's basically what they do all day.

I don't know their protocol on how they inform these companies, though. Maybe some contact already took place and AMD just didn't bother to release it themselves. But I'm guessing a state funded research institute will probably have some protocol like that in place.
Posted on Reply
#20
Aquinus
Resident Wat-man
btarunrthe researchers were able to use rogue host-level administrator, or malware within a hypervisor, to bypass SEV and copy decrypted information from the guest machine's memory.
Just in, my machine might be compromised if I give away my IP address, the port SSH is running on, my private key, and my password to an account with sudo access. :kookoo:
Posted on Reply
#21
eidairaman1
The Exiled Airman
Capitan HarlockThis kind of move without inform whoever is the company of the product is so lame .
Is like discovering a bad batch of tomatoes and instead of inform the seller you go to the press and saying stuff .
This don't make any sense .
Amd should take them to court because is not right at all .
Makes me wonder if someone is a shill there.
Slander and libel on this.
Posted on Reply
#22
Patriot
dwadeThe damage control team is already doing work.
*the group requiring honest reporting, This bullshit is published and ignores the actual issues.

Another side channel attack that is legitimate and effects Intel, AMD and ARM
“Speculative Store Bypass”
www.theverge.com/2018/5/21/17377994/google-microsoft-cpu-vulnerability-speculative-store-bypass-variant-4

www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html
www.amd.com/en/corporate/security-updates
Posted on Reply
#23
DeathtoGnomes
ahhh more BS that requires administrator access.
Posted on Reply
#24
Foobario
silentbogoThere's one more thing that looks suspicious.
Their paper is pretty much a slightly modified copycat of this one, published by members of Tangram Technologies from Shanghai back in December.

arxiv.org/ftp/arxiv/papers/1712/1712.05090.pdf

Their team lead, ZhaoHui Du, is very notable for being an Intel researcher and software engineer for almost 18 years. It's not a red flag by any means, but considering that Tangram was founded in 2017, it raises some concerns and suspicions.
Seems Intel has been funding a lot of research projects since the release of Zen. This is the second that has gained attraction in the internet media space.

I will become concerned when some of their poking and prodding of Ryzen/Epyc results in a weakness that doesn't require the perpetrator to have total access to the system they are trying to attack.

Next funded Intel hit piece will suggest that server farms using Epyc are susceptible to power outages should someone with a ladder and dynamite gain access to the transformer leading to the data center. And, of course, a desire to blow up the transformer.

Of course, this Epyc vulnerability will also require an inside man that can disable the backup power source within the data center.
Posted on Reply
#25
XiGMAKiD
silentbogoThere's one more thing that looks suspicious.
Their paper is pretty much a slightly modified copycat of this one, published by members of Tangram Technologies from Shanghai back in December.

arxiv.org/ftp/arxiv/papers/1712/1712.05090.pdf

Their team lead, ZhaoHui Du, is very notable for being an Intel researcher and software engineer for almost 18 years. It's not a red flag by any means, but considering that Tangram was founded in 2017, it raises some concerns and suspicions.
Intel just wanted to make sure Epyc are safe for customer so they can use it to replace Xeon :roll:
Posted on Reply
Add your own comment
Dec 22nd, 2024 16:26 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts