AMD has included processors based on the Zen 5 microarchitecture in the list of products affected by the EntrySign vulnerability, which allows bypassing the digital signature verification mechanism when updating microcode. Initially, it was thought that the vulnerability only affected AMD CPUs based on the 1st to 4th generation of the Zen microarchitecture. Thus, the vulnerability is applicable to processors such as the Ryzen 9000 (Granite Ridge), EPYC 9005 (Turin), Ryzen AI 300 (Strix Halo, Strix Point, Krackan Point), and Ryzen 9000HX (Fire Range).
In addition to updating the microcode, addressing the vulnerability on systems using SEV-SNP attestation also requires an update to the AMD SEV firmware, which is included in BIOS updates. AMD claims to have provided equipment manufacturers with a modified firmware (ComboAM5PI 1.2.0.3c AGESA) necessary to address the issue, but the final BIOS updates available to consumers may be released by manufacturers weeks or months later.
AMD employees have also proposed a patch to be included in the Linux kernel that blocks the loading of unofficial microcode updates (it is noted that proper microcode updates need to be installed along with the BIOS from the equipment manufacturer, but attempts have already emerged to create unofficial fixes by enthusiasts based on fragments of microcode extracted from the BIOS). Users are advised to wait for official BIOS updates.
The EntrySign vulnerability allows for changes to microcode, compromising the AMD SEV (Secure Encrypted Virtualization) mechanism used in virtualization systems for protection of virtual machines against interference from the hypervisor or the host system administrator. During an attack, it is possible to infiltrate the operation of guest systems protected by AMD SEV (Secure Encrypted Virtualization) and SEV-SNP (Secure Nested Paging) extensions, which provide guarantees of the integrity of virtual machine memory, isolate processor registers, and ensure secure operation with nested page tables.
The vulnerability arises from the use of the CMAC algorithm in the verification process of microcode instead of a reliable hash function. AMD uses a private RSA key to sign the microcode loaded into the processor with a digital signature, while distributing the public key as part of the microcode patch. To verify that the public key corresponds to the original RSA key pair, the processor matches the hash of the AMD public key, embedded during CPU manufacturing, with the hash of the public key specified in the patch.
Authenticating the microcode in the patch is done by comparing the hash supplied with the patch, secured by a digital signature (RSASSA-PKCS1-v1_5), and the hash computed based on the actual microcode provided in the patch. If the reference and computed hashes match, the patch is loaded into the CPU's internal memory. The problem is that instead of using the recommended cryptographically secure hash functions, the CMAC algorithm, which is not designed for such operations and is not resistant to collision attacks, is applied.
CMAC is not a hash function but implements a Message Authentication Code (MAC) that depends on the encryption key. The operation of AES-CMAC boils down to using the AES cryptographic algorithm and combining the result of its application with the next block of data using the XOR operation. This scheme ensures that changes in the input data lead to unpredictable changes in the output data. It is unacceptable to use CMAC as a hash function since anyone who knows the original encryption key can determine the intermediate encryption states and compute values that can compensate for changes in the input data such that the result of applying CMAC remains unchanged.
AMD uses a single encryption key for AES-CMAC, provided across all CPUs starting from Zen 1. Therefore, extracting this key from any AMD CPU will apply to all other CPUs. Researchers found that a known key, referenced in the NIST SP 800-38B guidelines for block cipher usage, is used for AES-CMAC encryption in AMD. Since AES-CMAC is used for hashing the embedded RSA key patch and the microcode content, identifying the AES-CMAC encryption key allows for substitution of the patch with another public RSA key and modification of the microcode content.
To create a counterfeit patch, it is sufficient to generate a new public key that produces the same hash as the original AMD public key, as well as find collisions for the digital signature. Collisions are formed by appending an additional block to the microcode, appearing as a set of random data. In this way, a modified microcode patch can be prepared that corresponds to the digital signature that the original AMD patch was certified with. The Zentool toolkit, which includes utilities for microcode analysis and creating patches for modifying microcode, is available under the Apache 2.0 license. To replace the microcode, permissions for executing code at the level of ring zero protection are needed (VT-x and AMD-V technologies allow the guest system to run with Ring 0 privileges).
Source: opennet.ru
