The “Ryzenfall” of AMD

The “Ryzenfall” of AMD

Security research firm CTS has disclosed four critical flaws in AMD’s latest CPU models based on the ZEN architecture: Ryzen and EPYC. Ironically enough the Secure Processor located on the main CPU is the source of the vulnerability. While the firm’s motivation is under some scrutiny due to poor reporting practices, the vulnerabilities appear to be real enough with some terrifying implications.

Usually, a compromised machine can be cleaned of the infection and defended again with the appropriate patches or software upgrades. Not anymore. Three of the flaws, dubbed Ryzenfall, Fallout, and Masterkey, allow an attacker to plant malware in a “secure enclave” thereby skipping all detection and other security controls such as Microsoft’s Credential Guard, Virtualization based Security, and AMD’s own firmware Trusted Platform Module (fTPM), or they can just brick your motherboard.

The flaws use the fact that the BIOS validation program can be tricked into believing a firmware update is a valid signed version when it isn’t. This allows the attacker to load malware inside the processor and the chipset that gets processed before any security or validation software runs, meaning that persistence is almost guaranteed. It can even block being overwritten by a new BIOS update.

The fourth flaw announced, Chimera, is not really a flaw. It’s a poorly designed manufacturer backdoor that was previously not-well-known and could be weaponized with some effort. Do you remember ASUSTek being forced to undergo 20 years of mandatory external security audits due to their negligent disregard for consumer privacy and protection? Well, ASUSTek owns ASMedia. ASMedia manufactures the ARM processor “Cortex-A5” which, you guessed it, is what AMD decided to use as their Secure Processor for the backbone of their fTPM instead of designing their own. Chimera allows the chipset to open up direct communications from the chipset itself to multiple peripheral interfaces including the WiFi, NIC, and USB controllers theoretically granting access to monitor the traffic and send traffic out to CnC servers without raising any flags.

The one piece of good news seems to be that Administrative Access is required prior to exploiting any of these vulnerabilities. I’ve seen too many networks to let that “good news” really alleviate my concern of these flaws being weaponized on a mass scale. However, if you follow best practices and separate your admin and user accounts, patch your software, and run up-to-date antivirus/antimalware you have a good chance of keeping your BIOS safe from this exploit.

Since AMD has only had a few days to ingest these flaws, we aren’t expecting a fix for these issues for the next several weeks, and not at all for Chimera. It is also possible that a software patch may not be enough to fully mitigate any of these vulnerabilities and we will be forced to either accept the risk and keep churning or do a full replace of our core system hardware.

Another element to this story is the process of disclosure used by the discovering firm. When Critical Path Security discovers vulnerabilities in products, we typically give companies 30 days to respond before disclosing our findings to the public. More serious flaws, like the NTP issues with Apple devices, were deemed so dangerous that Apple and it’s affected vendors were given even longer to respond–Patrick Kelley did not disclose the findings until the vendors had 90 days to develop patches before revealing them to the world at large. The report identifying these AMD flaws was delivered to AMD a mere 24 hours before being released to the general public. This is poor practice and it’s the belief of many in the security world that this firm stands to profit from AMD’s stock fluctuations rather than their bug-bounty program.

Where do we go from here? Demand a recall? Settle for half-hearted Operating System patches that help mitigate process exploitation but don’t actually address the hardware flaw? Alter our disclosure methods to those that drive a harsher penalty in the “Court of Public Opinion”? How egregious does a flaw, in what’s supposed to be the trusted platform on which we base all our other security on, need to be before we scream foul and demand reparations? How far can a company take its commercial advertising before unvalidated statements like “Trusted Platform Module”, “Secure Processor”, “Secure Fenced RAM”, and “Validated Boot” are considered fraudulent and misleading? Do we call it bad QA or blatant misrepresentation of functionality?

As an industry, we shake our heads and grumble. As a society, we have a mild panic attack and then forget about it. That raises the question, how many times have we just forgot about these massive oversights in delivering security to consumers or shifted blame from the manufacturer to the consumer for not configuring their device properly? Likely, thousands. How many devices with known unpatchable vulnerabilities are online right now? Millions. When is enough going to be enough? When is our collective security going to be more important than a few organization’s profit margins?

Leave a Reply

Close Menu