Tuesday, March 13th 2018

13 Major Vulnerabilities Discovered in AMD Zen Architecture, Including Backdoors

Security researchers with Israel-based CTS-Labs, have discovered a thirteen security vulnerabilities for systems based on AMD Zen processors. The thirteen new exploits are broadly classified into four groups based on the similarity in function of the processor that they exploit: "Ryzenfall," "Masterkey," "Fallout," and "Chimera."

The researchers "believe that networks that contain AMD computers are at a considerable risk," and that malware can "survive computer reboots and re-installations of the operating system, while remaining virtually undetectable by most endpoint security solutions," such as antivirus software. They also mention that in their opinion, "the basic nature of some of these vulnerabilities amounts to complete disregard of fundamental security principles. This raises concerning questions regarding security practices, auditing, and quality controls at AMD."
Since this story went up some follow ups were posted:1. "Masterkey": This is an exploit of the Secure Boot feature, which checks if nothing has been tampered with on your machine while it was powered down (i.e. changes in firmware, hardware, or the last software state before shutdown). The Masterkey vulnerability gets around this environment integrity check by using an infected system BIOS, which can be flashed even from within Windows (with administrative privileges). This does not mean that the user has to modify and flash the BIOS manually before becoming vulnerable, the malware can do that on the fly once it is running. Theoretically, Secure Boot should validate the integrity of the BIOS, but apparently this can be bypassed, exploiting bugs in the Secure Processor's metadata parsing. Once the BIOS signature is out of the way, you can put pretty much any ARM Cortex A5 compatible code into the modified BIOS, which will then execute inside the ARM-based Secure Processor - undetectable to any antivirus software running on the main CPU, because the antivirus software running on the CPU has no way to scan inside the Secure Processor.

2. "Ryzenfall" is a class of vulnerabilities targeting Secure Processor, which lets a well-designed malware stash its code into the Secure Processor of a running system, to get executed for the remainder of the system's up-time. Again, this attack requires administrative privileges on the host machine, but can be performed in real-time, on the running system, without modifying the firmware. Secure Processor uses system RAM, in addition to its own in-silicon memory on the processor's die. While this part of memory is fenced off from access by the CPU, bugs exist that can punch holes into that protection. Code running on the Secure Processor has complete access to the system; Microsoft Virtualization-based Security (VBS) can be bypassed and additional malware can be placed into system management storage, where it can't be detected by traditional antivirus software. Windows Defender Credentials Guard, a component that stores and authenticates passwords and other secure functions on the machine, can also be bypassed and the malware can spread over the network to other machines, or the firmware can be modified to exploit "Masterkey", which persists through reboots, undetectable.

3. "Fallout": This class of vulnerabilities affects only AMD EPYC servers. It requires admin privileges like the other exploits, and has similar effects. It enables an attacker to gain access to memory regions like Windows Isolated User Mode / Kernel Mode (VTL1) and Secure Management RAM of the CPU (which are not accessible, even with administrative privileges). Risks are the same as "Ryzenfall", the attack vector is just different.

4. "Chimera": This class of vulnerabilities is an exploitation of the motherboard chipset (e.g. X370 also known as Promontory). AMD outsourced design of their Ryzen chipsets to Taiwanese ASMedia, which is a subsidiary of ASUS. You might know the company from the third-party USB 3.0 and legacy PCI chips on many motherboards. The company has been fined for lax security practices in the past, and numerous issues were found in their earlier controller chips. For the AMD chipset, it looks like they just copy-pasted a lot of code and design, including vulnerabilities. The chipset runs its own code that tells it what to do, and here's the problem: Apparently a backdoor has been implemented that gives any attacker knowing the right passcode full access to the chipset, including arbitrary code execution inside the chipset. This code can now use the system's DMA (direct memory access) engine to read/write system memory, which allows malware injection into the OS. To exploit this attack vector, administrative privileges are required. Whether DMA can access the fenced off memory portions of the Secure Processor, to additionally attack the Secure Processor through this vulnerability, is not fully confirmed, however, the researchers verified it works on a small number of desktop boards. Your keyboard, mouse, network controllers, wired or wireless, are all connected to the chipset, which opens up various other attack mechanisms like keyloggers (that send off their logs by directly accessing the network controller without the CPU/OS ever knowing about these packets), or logging all interesting network traffic, even if its destination is another machine on the same Ethernet segment. As far as we know, the tiny 8-pin serial ROM chip is connected to the CPU on AMD Ryzen platform, not to the chipset or LPCIO controller, so infecting the firmware might not be possible with this approach. A second backdoor was found that is implemented in the physical chip design, so it can't be mitigated by a software update, and the researchers hint at the requirement for a recall.

AMD's Vega GPUs use an implementation of the Secure Processor, too, so it is very likely that Vega is affected in a similar way. An attacker could infect the GPU, and then use DMA to access the rest of the system through the attacks mentioned above.

The researchers have set up the website AMDFlaws.com to chronicle these findings, and to publish detailed whitepapers in the near future.

AMD provided us with the following statement: "We have just received a report from a company called CTS Labs claiming there are potential security vulnerabilities related to certain of our processors. We are actively investigating and analyzing its findings. This company was previously unknown to AMD and we find it unusual for a security firm to publish its research to the press without providing a reasonable amount of time for the company to investigate and address its findings. At AMD, security is a top priority and we are continually working to ensure the safety of our users as potential new risks arise."

Update March 14 7 AM CET: It seems a lot of readers misunderstand the BIOS flashing part. The requirement is not that the user has to manually flash a different BIOS first before becoming vulnerable. The malware itself will modify/flash the BIOS once it is running on the host system with administrative privileges. Also, the signed driver requirement does not require a driver from any specific vendor. The required driver (which is not for an actual hardware device and just provides low-level hardware access) can be easily created by any hacker. Signing the driver, so Windows accepts it, requires a digital signature which is available from various SSL vendors for a few hundred dollars after a fairly standard verification process (requires a company setup with bank account). Alternatively an already existing signed driver from various hardware utilities could be extracted and used for this purpose.
Source: Many Thanks to Earthdog for the tip
Add your own comment

482 Comments on 13 Major Vulnerabilities Discovered in AMD Zen Architecture, Including Backdoors

#301
John Naylor
Im still waiting to see a "aww... look at what happened to this guy" story from any of these "major defects"
Posted on Reply
#302
FordGT90Concept
"I go fast!1!11!1!"
I just wanted to say that I'm glad TechPowerUp is doing editorial updates to an article. I'd like to see improvements in terms of making it clear what changed in each update though. It looks like, in its present state, only one update is clearly marked at the bottom.
Posted on Reply
#303
dorsetknob
"YOUR RMA REQUEST IS CON-REFUSED"
Mussels"Fuck"
Posted on Reply
#304
W1zzard
FordGT90ConceptI just wanted to say that I'm glad TechPowerUp is doing editorial updates to an article. I'd like to see improvements in terms of making it clear what changed in each update though. It looks like, in its present state, only one update is clearly marked at the bottom.
Just added two links to follow up stories and bumped the update number.
Posted on Reply
#305
bug
John NaylorIm still waiting to see a "aww... look at what happened to this guy" story from any of these "major defects"
Same thing that happened because of Spectre and Meltdown, I guess.

Seriously speaking though these aren't about what happens to this or that guy. These are more about ways to breach into servers and other stuff that has a good chance of going unnoticed. Think someone managing to escape their VM on a rented server and reading others' data.
These aren't the kind of vulnerabilities your next door script kiddie will abuse at will.

@W1zzard If you would properly prefix each update with "Update 1", "Update 2" and so on, that would be dreamy.
Posted on Reply
#306
W1zzard
bugIf you would properly prefix each update with "Update 1", "Update 2" and so on, that would be dreamy.
The first updates were in-text changes and in short succession, so difficult to prefix those. Will try to handle this better in the future.
Posted on Reply
#308
bug
ikekeAccording to AT call with CTS labs the exploits also require bare metal install of the OS (and OS has to be Windows?).

www.anandtech.com/show/12536/our-interesting-call-with-cts-labs
A hardware flaw that needs a specific OS to exploit seems uber-suspicious.

Edit: Then again, seeing how mobo makers implement UEFI just so that it works on Windows, maybe not?
Posted on Reply
#309
HTC
ikekeAccording to AT call with CTS labs the exploits also require bare metal install of the OS (and OS has to be Windows?).

www.anandtech.com/show/12536/our-interesting-call-with-cts-labs
Then it turns out i was more on point then i thought:
HTCAgreed!

Question: i read (skimmed) the whitepaper but i didn't see a mention of Linux or other OSs other then Windows ... doesn't that mean it's Windows vulnerabilites when using Zen based hardware?
I'll ask again: doesn't that mean it's Windows vulnerabilites when using Zen based hardware?
Posted on Reply
#310
FordGT90Concept
"I go fast!1!11!1!"
W1zzardThe first updates were in-text changes and in short succession, so difficult to prefix those. Will try to handle this better in the future.
Could underline changes and subscript the update number at the end of each one.
Posted on Reply
#311
anubis44
The longer you leave up this fake security news article, the less likely it becomes that I'll keep visiting this site.
Posted on Reply
#312
lexluthermiester
anubis44The longer you leave up this fake security news article, the less likely it becomes that I'll keep visiting this site.
This is not fake news. Much of it has either been verified or is looking very plausible. But if you want to leave, your loss..
Posted on Reply
#313
ikeke
Even if everything they say turns out to be truth then it still leaves the question why they gave AMD less than 24h notification on these before publishing "amdflaws" and why none of this was validated by independant review before going public.

These two, along with references to personal profit they may gain from publishing the alleged exploits, do not paint them as security researchers. More like guns for hire.
Posted on Reply
#314
anubis44
lexluthermiesterThis is not fake news. Much of it has either been verified or is looking very plausible. But if you want to leave, your loss..
It's utter garbage. You have to be sitting at the computer AND know the admin password to do any of these. If somebody gets admin rights and is sitting at your computer, you're ALREADY screwed. This was a stock market short-sell hit piece plain and simple. Please just accept this and move on. Nothing to see here.

HW News: CTS Labs Avoids Questions

Linus Torvalds slams CTS Labs over AMD vulnerability report
Linux's creator said he thinks CTS Labs' AMD chip security report "looks more like stock manipulation than a security advisory" and questions an industry.
www.zdnet.com/article/linus-torvalds-slams-cts-labs-over-amd-vulnerability-report/

Evidence Suggests Report on AMD Security Was Financially Motivated
wccftech.com/report-alleges-amd-ryzen-epyc-cpus-suffer-13-fatal-security-flaws/
Posted on Reply
#315
lexluthermiester
anubis44It's utter garbage. You have to be sitting at the computer AND know the admin password to do any of these. If somebody gets admin rights and is sitting at your computer, you're ALREADY screwed.
As most of these problems are aimed at remote attack vectors it would seem you have not been reading up on the details of these vulnerabilities.
anubis44This was a stock market short-sell hit piece plain and simple.
Conspiracy theory. Even if true, such efforts didn't work on any level.
anubis44Please just accept this and move on.
Oh please.
anubis44Nothing to see here.
As several of these vulnerabilities have been verified, there is very clearly something "to see" and be concerned about. If you want to bury your head in the sand that's your choice. The rest of us will be responsible, stay objective and focus on facts & evidence.
Posted on Reply
#316
Totally
lexluthermiesterAs most of these problems are aimed at remote attack vectors
That are not executable without aforementioned password and physical access to computer. ATM to me it would be like a car thief stealing a car by smashing in a window after finding the door unlocked with the keys in the ignition.
The rest of us will be responsible, stay objective and focus on facts & evidence.
Your opinion has clearly gone a bit beyond that.
Posted on Reply
#317
lexluthermiester
TotallyThat are not executable without aforementioned password and physical access to computer.
Not a difficult task depending on the target and goal. You'd be surprised how vulnerable most systems are to directed remote attacks and how easy it is to gain admin access.
TotallyYour opinion has clearly gone a bit beyond that.
My opinion is that of focusing on the problems presented by the vulnerabilities, not on the politics or brand loyalties of the companies involved. The motivations of the actors behind the discoveries are irrelevant to the discoveries themselves.

The perspectives offered by "anubis44" focus on the politics of the people making the discoveries rather than the facts and details of the discoveries themselves, which is not helpful or constructive. "abubis44" is also calling out TPU for reporting on the information claiming some sort of bias or defaming effort on their part which is complete rubbish and narrow minded thinking. Again, not helpful or constructive. TPU is reporting information as it comes to light and doing a damn good job keeping updated and up to speed with developments as they occur. "anubis44" also made a veiled "threat" of abandoning the site if they didn't discontinue what "anubis44" considers unacceptable. My response to that sad little remark implied "don't let the door hit you on the way out".

The occurrence of "certain" people "getting outraged" over silly things that ultimately don't matter has been on the rise lately. The staff have had to deal with it even more than us users. Both groups are getting tired of it.
ikekeEven if everything they say turns out to be truth then it still leaves the question why they gave AMD less than 24h notification on these before publishing "amdflaws" and why none of this was validated by independent review before going public.
The technical details were not released with the announcement, only the conceptual details. This seems to be a continuing misunderstanding on the part of the general public. The technical details and proof of concept samples were only released to AMD and other responsible party's/entity's to be validated and fixed. The announcement was the only part of this release that was done with only 24hr notice, which CTS Labs admitted they could have handled better. Everything else was handled in a seemingly appropriate manner.

Trying to vilify and berate a group for what is clearly a minor mistake by conjuring up fanciful conspiracies is an effort of foolishness, not objectivity.
Posted on Reply
#318
ikeke
I'm still calling BS on the excuses.

Giving someone 90d headsup on allegedly critical flaw vs taking the time to craft a web site and videos with greenscreen just to paddle some FUD, not to mention some stock shortseller pushing 20+ page FUD article minutes after you go public? Yeah, all good...

www.anandtech.com/show/12536/our-interesting-call-with-cts-labs

IC: Would there be any circumstance in which you would be willing to share the details of these vulnerabilities and exploits under NDA with us?
YLZ: We would love to, but there is one quirk. According to Israel export laws, we cannot share the vulnerabilities with people outside of Israel, unless they are a company that provides mitigations to such vulnerabilities. [ikeke:this is BS] That is why we chose the list. But look, we are interested in the validation of this – we want people to come out and give their opinion, but we are only limited to that circle of the vendors and the security companies, so that is the limitation there.

And, to repeat myself, if they want to see how AMD is "unable" to fix issues then perhaps someone can point them towards latest example that i know of, which is a fix for, well-well AMD-PSP :rolleyes:
seclists.org/fulldisclosure/2018/Jan/12
Posted on Reply
#319
lexluthermiester
@ikeke
That comment showcases what I was saying. Your complaint focus's on the politics of the company that made the discoveries instead of the technical details of the discoveries themselves. Not saying you're wrong either. The way CTS conduced themselves was very much less than ideal. However one could also say that they knew what they had on their hands, knew it would be a big deal and made efforts beforehand to be prepared with presentations. The only real problem I see is the way they handled the announcement. Not buying into this conspiracy nonsense one bit.

This kind of thing has happened before. Someone makes a discovery, knows it's big, prepares for the announcement and disclosure of such and then messed up the timing of it of all. This has happened in all area's of society, not just the tech sector. Intel, AMD, Nvidia, IBM, HP, Dell, etc, etc have all made these kinds of mistakes. Call it what it is and lets move on..
Posted on Reply
#320
ikeke
But them saying that they "messed up" and the available facts do not add up.
Too many inconsistencies.
Im not one to veer into conspiracies but they have shown way too many markers for bad intentions and against accidental mishap. Claiming to have "16 years of experience" and then this? Yeah, right.

www.gamersnexus.net/industry/3264-hw-news-cts-labs-update-r5-2600x-specs-dead-wafers-more

One of our questions was about NineWells Capital, with which CTS Labs CFO Yaron Luk-Zilberman has held a position. We asked what the relationship was between NineWells Capital, a hedge-fund firm, and CTS Labs. The company provided this statement: “NineWells Capital is a long-oriented financial partnership that was managed by our CFO, Yaron Luk-Zilberman. He no longer actively manages that partnership. NineWells has no financial position in AMD, Intel, or any other semiconductor company.”

We are still waiting for clarity on this. Some digging revealed an SEC document that lists Yaron Luk-Zilberman as President of NineWells Capital as recently as March 8, 2018, just days before CTS Labs released its exploit list. We can’t make links at this time, but we have asked for clarity on this point. Luk-Zilberman was also listed on the CTS-Labs website as a Managing Director of NineWells Capital.

Regarding Viceroy, we asked this question: “What is CTS Labs' affiliation with Viceroy Research? Did Viceroy commission CTS Labs for this report? Have the two companies had any previous connections or affiliation?”

The response was as follows: “"Viceroy is not a client of CTS. We did not send Viceroy our report. For any additional questions, please ask Viceroy."

Unfortunately, this response side-steps half the other questions -- like our question about the affiliation between Viceroy Research and CTS Labs. There is some affiliation, even if unofficial or distant. Viceroy Research is on-record with Reuters stating that they received the CTS Labs research document prior to launch, via leak, and took a “sizeable short” on AMD as a result. Given the small size of CTS Labs, it’s interesting that a leak would happen to such a specific firm.
Posted on Reply
#321
R0H1T
lexluthermiester@ikeke
That comment showcases what I was saying. Your complaint focus's on the politics of the company that made the discoveries instead of the technical details of the discoveries themselves. Not saying you're wrong either. The way CTS conduced themselves was very much less than ideal. However one could also say that they knew what they had on their hands, knew it would be a big deal and made efforts beforehand to be prepared with presentations. The only real problem I see is the way they handled the announcement. Not buying into this conspiracy nonsense one bit.

This kind of thing has happened before. Someone makes a discovery, knows it's big, prepares for the announcement and disclosure of such and then messed up the timing of it of all. This has happened in all area's of society, not just the tech sector. Intel, AMD, Nvidia, IBM, HP, Dell, etc, etc have all made these kinds of mistakes. Call it what it is and lets move on..
I think the problem, for many on this forum & elsewhere, is that CTS hasn't disclosed the more technical details & PoC to the public or even the press. So there's no way to know how serious they are, like flash 0day level or closer to spectre/meltdown wrt PSP & ASMedia chipsets.

If they are really serious about helping us, then why not tell us what's wrong & how bad is it? I have a Z97 with 2 Asmedia USB ports, am I safe(r) after these disclosures?
Posted on Reply
#322
R-T-B
Totallyphysical access to computer.
Can we please stop repeating this? It's not what the report claims.

At this point the best we can do is wait and see. But the fact that AMD did not debunk this immediately firmly takes it out of the "fake news" category in my eyes, FWIW.
Posted on Reply
#323
lexluthermiester
ikekeBut them saying that they "messed up" and the available facts do not add up. Too many inconsistencies. I'm not one to veer into conspiracies but they have shown way too many markers for bad intentions and against accidental mishap. Claiming to have "16 years of experience" and then this? Yeah, right.
That assumes that all of the information has been disclosed. It hasn't so a lot of assumptions are being made. And 16 years might be collective for all of the people involved. Again, this information focuses on the politics of the people involved instead of the merit of the vulnerabilities disclosed, which we already know some of them to be valid.
R0H1TI think the problem, for many on this forum & elsewhere, is that CTS hasn't disclosed the more technical details & PoC to the public or even the press. So there's no way to know how serious they are, like flash 0day level or closer to spectre/meltdown wrt PSP & ASMedia chipsets.
Correct, they didn't! And that is what is responsible about it. They released only the conceptual descriptions of the vulnerabilities to the public, not the full technical details.
Posted on Reply
#324
R-T-B
lexluthermiesterCorrect, they didn't! And that is what is responsible about it. They released only the conceptual descriptions of the vulnerabilities to the public, not the full technical details.
That is the big point people seem to miss about why the "60 day disclosure warning" did not occur here, isn't it?

The big difference here is: They aren't disclosing it to the public at all. Period.
Posted on Reply
#325
R0H1T
lexluthermiesterThat assumes that all of the information has been disclosed. It hasn't so a lot of assumptions are being made. And 16 years might be collective for all of the people involved. Again, this information focuses on the politics of the people involved instead of the merit of the vulnerabilities disclosed, which we already know some of them to be valid.

Correct, they didn't! And that is what is responsible about it. They released only the conceptual descriptions of the vulnerabilities to the public, not the full technical details.
And I'll refer you back to the post where 4 different researchers found spectre/meltdown within a space of 3 to 6 months after GPZ first reported it.
If there's a flaw, chances are ~ it was already known or will be uncovered quickly by those who want to exploit it.
Posted on Reply
Add your own comment
Jan 24th, 2025 01:33 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts