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:
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
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:
- CTS Labs Sent AMD and Other Companies a Research Package with Proof-of-Concept Code
- CTS Labs Posts Some Clarifications on AMD "Zen" Vulnerabilities
- CTS-Labs Releases Masterkey Exploit Proof-of-Concept Video
- Initial AMD Technical Assessment of CTS Labs Research
- Windows Credential Guard bypass on Ryzen, proof-of-concept video
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.
482 Comments on 13 Major Vulnerabilities Discovered in AMD Zen Architecture, Including Backdoors
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.
www.anandtech.com/show/12536/our-interesting-call-with-cts-labs
Edit: Then again, seeing how mobo makers implement UEFI just so that it works on Windows, maybe not?
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.
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/
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. 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.
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
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..
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.
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?
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.
The big difference here is: They aren't disclosing it to the public at all. Period.
If there's a flaw, chances are ~ it was already known or will be uncovered quickly by those who want to exploit it.