Asus lets processor security fix slip out early, AMD confirms patch in progress

AMD has confirmed at least some of its microprocessors suffer a microcode-related security vulnerability, the existence of which accidentally emerged this month after a fix for the flaw appeared in a beta BIOS update from PC maker Asus.

All we know for now is that the security issue is a "microcode signature verification vulnerability." Microcode is information typically loaded into the processor by the system firmware or operating system at boot time that dictates the way various parts of the chip work, to put it simply. Microcode can be used to add and fix functionality within the processor without having to physically replace the component, which is convenient.

Crucially, the format of the microcode is usually proprietary to the maker of the processor (in this case, AMD) so people generally can't come up with their own microcode and heavily customize their CPUs. There are also defense mechanisms in place to ensure only official microcode can be loaded, which usually includes checking the digital signature of the code before it's loaded.

We're speculating here but a microcode signature verification vulnerability may involve being able to load into an AMD processor microcode that should be rejected, but isn't, and thus someone may be able to tweak the way their CPUs function, or stop the thing from working entirely. Usually microcode can only be loaded by a privileged process, such as the OS kernel or BIOS firmware, and while something or someone malicious on your system with that level of access is already pretty bad, you probably don't want them to start screwing with a microcode-related vulnerability either.

So far, it's not looking too critical, and it's the manner in which info is leaking out that is the story here.

Uncovered

Our attention was drawn to the AMD flaw by a public mailing list post from Tavis Ormandy, a top bug-finder at Google's Project Zero. He pointed out that Asus had emitted a beta BIOS update for its gaming motherboards that mentioned a fix for the aforementioned AMD vulnerability in its release notes – crucially, before AMD had a chance to distribute an official advisory about said vuln.

Those notes have since been edited to remove a reference to AMD's microcode issue, though they still acknowledge the patching of a separate memory overflow security flaw in PeCoffLoader.

"It looks like an OEM leaked the patch for a major upcoming CPU vulnerability, ie: 'AMD Microcode Signature Verification Vulnerability,'" Ormandy wrote on Tuesday. "I'm not thrilled about this. The patch is not currently in linux-firmware, so this is the only publicly available patch."

AMD confirmed to The Register some of its products have an issue that needs fixing, and that a patch will be released and disclosed as normal shortly. "AMD is aware of a newly reported processor vulnerability. Execution of the attack requires both local administrator level access to the system, and development and execution of malicious microcode," the Ryzen giant told us.

AMD’s remarks to The Register suggest it’s more worried that its customers could fall for fake fixes than the impact of the problem itself.

"AMD has provided mitigations and is actively working with its partners and customers to deploy those mitigations,” the biz told us. “AMD recommends customers continue to follow industry-standard security practices and only work with trusted suppliers when installing new code on their systems. AMD plans to issue a security bulletin soon with additional guidance and mitigation options."

However, the chip designer hasn’t yet revealed which of its products are impacted.

While the world waits for that guidance, speculation about the flaw has begun.

"Is this fix effective, or can it be bypassed via a downgrade attack?" asked Demi Marie Obenour, a software developer for Invisible Things on the same security mailing list. She suggested that although exploitation is likely limited to highly privileged users and software, the bug could be used to undo super-low-level system security protections.

"Since microcode loading can (hopefully!) only be done in ring 0 and SVM root mode, this means that one needs OS kernel access to perform an exploit. However, if an attacker could load arbitrary microcode, they could compromise SMM, SEV-SNP, and DRTM, so this is still pretty bad."

Hey, worse things can happen. ®