Thursday, March 15th 2018
CTS Labs Posts Some Clarifications on AMD "Zen" Vulnerabilities
CTS-Labs the research group behind the AMD "Zen" CPU vulnerabilities, posted an addendum to its public-release of the whitepaper, in an attempt to dispel some of the criticism in their presentation in the absence of technical details (which they shared with AMD and other big tech firms). In their clarification whitepaper, quoted below, they get into slightly more technical details on each of the four vulnerability classes.
Clarification About the Recent Vulnerabilities
[CTS Labs] would like to address the many technical points and misunderstandings with a few technical clarifications about the vulnerabilities. The vulnerabilities described in our site are second-stage vulnerabilities. What this means is that the vulnerabilities are mostly relevant for enterprise networks, organizations and cloud providers.
Computers on enterprise networks occasionally get compromised - whether through phishing attempts, zero-day exploits or employees downloading the wrong file. High-security enterprise networks are equipped to deal with these kinds of "every-day" attacks. They do this by keeping their systems up to date, enabling security features, and employing additional measures such as endpoint security solutions.
The vulnerabilities described in amdflaws.com could give an attacker that has already gained initial foothold into one or more computers in the enterprise a significant advantage against IT and security teams.
The only thing the attacker would need after the initial local compromise is local admin privileges and an affected machine. To clarify misunderstandings - there is no need for physical access, no digital signatures, no additional vulnerability to reflash an unsigned BIOS. Buy a computer from the store, run the exploits as admin - and they will work (on the affected models as described on the site).
Attackers in possession of these vulnerabilities would receive the following additional capabilities:
These are the machines we have tested the vulnerabilities on. On our site, every red circle in the vulnerabilities map represents a working PoC that was tested in our lab.
This is the list of hardware that has been tested in our lab:
Requirements
Requirements:
The MASTERKEY set of vulnerabilities enable an attacker to execute unsigned code inside the PSP. Totaling a complete compromise of the Secure Processor. The exploit reflashes the BIOS to take advantage of the vulnerability:
Requirements:
The CHIMERA set of vulnerabilities are a set Manufacturer Backdoors left on the AMD Chipset, developed by Taiwanese company ASMedia.
Source:
Safe Firmware
[CTS Labs] would like to address the many technical points and misunderstandings with a few technical clarifications about the vulnerabilities. The vulnerabilities described in our site are second-stage vulnerabilities. What this means is that the vulnerabilities are mostly relevant for enterprise networks, organizations and cloud providers.
Computers on enterprise networks occasionally get compromised - whether through phishing attempts, zero-day exploits or employees downloading the wrong file. High-security enterprise networks are equipped to deal with these kinds of "every-day" attacks. They do this by keeping their systems up to date, enabling security features, and employing additional measures such as endpoint security solutions.
The vulnerabilities described in amdflaws.com could give an attacker that has already gained initial foothold into one or more computers in the enterprise a significant advantage against IT and security teams.
The only thing the attacker would need after the initial local compromise is local admin privileges and an affected machine. To clarify misunderstandings - there is no need for physical access, no digital signatures, no additional vulnerability to reflash an unsigned BIOS. Buy a computer from the store, run the exploits as admin - and they will work (on the affected models as described on the site).
Attackers in possession of these vulnerabilities would receive the following additional capabilities:
- Persistency: Attackers could load malware into the AMD Secure Processor before the CPU starts. From this position they can prevent further BIOS updates and remain hidden from security products. This level of persistency is extreme - even if you reinstall the OS or try to reflash the BIOS - it won't work. The only way to remove the attacker from the chip, would be to start soldering out chips. (we have seen a motherboard that had a socket where you can switch chips - then you could just put a new SPI chip).
- Stealth: Sitting inside the AMD Secure Processor or the AMD Chipset is, at the moment, outside the reach of virtually all security products. AMD chips could become a safe haven for attackers to operate from.
- Network Credential Theft: The ability to bypass Microsoft Credentials Guard and steal network credentials, for example credentials left by the IT department on the affected machine. We have a PoC version of mimikatz that works even with Credential Guard enabled. Stealing domain credentials could help attackers to move to higher value targets in the network.
- Specific AMD Secure Processor features for cloud providers, such as Secure Encrypted Virtualization, could be circumvented or disabled by these vulnerabilities.
These are the machines we have tested the vulnerabilities on. On our site, every red circle in the vulnerabilities map represents a working PoC that was tested in our lab.
This is the list of hardware that has been tested in our lab:
- BIOSTAR B350 GT3 Ryzen Motherboard.
- GIGABYTE AB350-GAMING 3
- HP EliteDesk 705 G3 SFF Ryzen Pro machine
- HP Envy X360 Ryzen Mobile Laptop
- TYAN B8026T70AV16E8HR EPYC SERVER
- GIGABYTE MZ31-AR0 EPYC SERVER
Requirements
- Physical access is not required. An attacker would only need to be able to run an EXE with local admin privileges on the machine.
- Write to SMM memory, leading to code execution in SMM.
- Reading and/or tampering with Credential Guard VTL-1 memory through the PSP.
- Ryzenfall-4, which achieves code execution inside the PSP, leads to all the attacker capabilities described above, as well as the capability to tamper with the PSP and its security features.
- An attacker can use RYZENFALL or FALLOUT to bypass Windows Credential Guard, steal network credentials, and then use these to move laterally through Windows-based enterprise networks
Requirements:
- Physical access is not required. An attacker would only need to be able to run an EXE with local admin privileges on the machine.
- Wait for reboot.
The MASTERKEY set of vulnerabilities enable an attacker to execute unsigned code inside the PSP. Totaling a complete compromise of the Secure Processor. The exploit reflashes the BIOS to take advantage of the vulnerability:
- On some motherboards - this works out of the box. This is because PSP firmware is often ignored by BIOS signature checks.
- In other cases - RYZENFALL #1-2 could be used as a prerequisite for MASTERKEY to achieve code execution in SMM and bypass BIOS signature checks made in SMM code.
- Even if all else fails, we believe using RYZENFALL-4 to write to SPI flash from inside the PSP is probably possible.
Requirements:
- Physical access is not required. An attacker would only need to be able to run an EXE with local admin privileges on the machine.
The CHIMERA set of vulnerabilities are a set Manufacturer Backdoors left on the AMD Chipset, developed by Taiwanese company ASMedia.
- This allows for an attacker to inject malicious code into the chip and take over the chipset (Read/Write/Execute).
- One set of backdoors in implemented in firmware, while the other is implemented in the actual logic gates of the chip (ASIC). Both yield to the same impact.
89 Comments on CTS Labs Posts Some Clarifications on AMD "Zen" Vulnerabilities
Feel free to read this guide , How to flash Modded Bios (Yep So damn many hard STEP ):
puissanceled.com/vrac/Bios_modding/EN.html
Edit : oh i forgot something ,on my ASUS Prime X370 Pro , i updated Bios but I can't revert back to Old Bios, This does Not allow me ,I don't know it's ASUS or New Version of AMD AGESA 1.0.0.6
Also, most of these still seem to require physicall access so.
Edit, quoted wizz by mistake.
*) There have been ways to do privilege escalation.
Note: I'm not commenting on the validity of the claimed vulnerabilities by CTS-Labs. I would encourage everyone to remain skeptical and wait for potential evidence.
Every CPU has flaws. Live with it. It's so complex and the focus is more on performance then hardened security.
However it suprises me that the Ryzen pro has these simular flaws, when bios is modded. Ryzen pro is being sold as a 'safer' CPU compared to normal ryzen.
www.gamersnexus.net/industry/3260-assassination-attempt-on-amd-by-viceroy-research-cts-labs
Anyway they agree that the flaws threat is there, and that it needs further analysis.
i ask because anytime you run an exe, you need to click yes it can run
unless of course you've disabled uac
We can't all be like CTS labs and post a disclaimer that relieves them of all liability if what they say is actually false.
If there's an article people don't want to read, don't read it. No one is twisting anyone else's arm. Complaining about doesn't help anything.
I'm sure deep down most staff want AMD to do something amazing to keep prices down for both Intel and AMD users, aka the consumer no matter the camp wins.
www.anandtech.com/show/12536/our-interesting-call-with-cts-labs
So almost all motherboards that have Asmedia chipsets, including millions of Intel motherboards, are affected by CTS self proclaimed "vuneribility" Really strange why they choose to only target AMD. I wonder.
Also the final part of their conversation is almost comical:
Anandtech: Who do you work for?
CTS: Sorry bruh gotta go.
hahaha
What I see as an issue is selling of used chips thar are compromised where user had direct access to chip as admin and modified it. That is however a legit concern. Still, I wonder how such CPU would cause a concern in terms of what useful can you actually put into it permanently that would then work in a destination system as a security or privacy risk.
And then most comical is their statement that they have 16 years of experience in the field. What field???What's even more appalling given the context is that they said that they discovered the ASMedia bugs about a year ago. That is more than ample time to legitimately report their findings. But no they sit on it waiting for the right moment to spank AMD specifically. Why AMD specifically when as they claim the bugs/back doors affect every motherboard that uses said ASMedia chips?This shit stinks to high heaven.
They've got lots to hide & no real answers to tough/straight questions.
At the end of the day, while there is room for abuse of this feature, and it's a slippery slope and a thin red line... TPU would not have had to implement it if certain people didn't keep posting statements that are outright untrue, complete nonsense, or are of the form "LOL company <X> is teh evil because of <FUD>". I'd also encourage you to remember that these are TPU's forums, not yours, and as such they can do whatever they damn well please.
On to the topic at hand...
While I agree that actually exploiting these vulnerabilities is nowhere near as easy as Meltdown/Spectre, the fact of the matter remains that they are still vulnerabilities. Let's say that an attacker builds a phishing email that looks like it's from a motherboard vendor, and sends it to a list of email addresses obtained from one of the hundreds of account dumps online. That email redirects to a phishing website that recommends users to download an EXE from it to "patch" their computer's Ryzen vulnerabilitieis. That EXE, of course, contains code that exploits some, or all, of those vulnerabilities. Users are gonna download that file, run it, say "yes" when prompted by UAC, and boom, they're compromised.
So discarding these as "real" vulnerabilities because they need admin access is shortsighted, because users (as always) are the weakest link in computer security.
>Windows Credential Guard
>Windows-based enterprise networks
>Signed driver on Windows (for chimera)
I wonder why they haven't even mentioned Linux, which, when it comes to EPYC line and to a lesser degree, Threadripper line, is basically what any sensible enterprise would be running on those.
The complete lack of mention is really odd. At the very least, they're expected to mention that it's untested, if they haven't touched that bit. But these guys? Nothing.
(Of course there's also OS X, but I am not sure if any current Apple systems have AMD cpus in them at all.)