Researchers discovered a use-after-free flaw in AMD Zen 2 processors, which could allow a malicious actor to steal sensitive data, such as passwords and encryption keys. While many cloud environments have workloads running on affected CPUs, we estimate Zenbleed is not likely to be impactful in cloud environments.

We will update this blogpost as more information is published. 

What is CVE-2023-20593? 

CVE-2023-20593 is a security vulnerability caused by improper handling of the vzeroupper instruction during speculative execution, which is a common performance-enhancing technique used in all modern processors. Unlike many other hardware vulnerabilities that rely on side-channels (ex. Rowhammer, Meltdown, and Spectre), this attack works reliably and with immediate results with few prerequisites, other than that the host must be running an AMD Zen 2 class processor.    

The researcher employed fuzzing and performance counters to identify specific hardware events. He validated his findings using the "Oracle Serialization" approach. By using the "Oracle Serialization" technique, the researcher compared the execution of a randomly generated program with its serialized oracle. This comparison revealed inconsistencies, ultimately leading to the discovery of CVE-2023-20593 in Zen 2 CPUs. 

Exploiting this flaw allowed the researcher to trigger an optimized exploit and gain access to sensitive data from various system operations. Even operations in virtual machines, isolated sandboxes, containers, and other environments were vulnerable to data leakage. 

 It has been shown that on vulnerable systems, you can read the memory of a privileged process from an unprivileged process.  This vulnerability therefore allows for a local privileged read, which means that an attacker must first achieve code execution on the system to exploit it effectively. 

What scenarios are most likely for exploitation in the cloud? 

In theory, this vulnerability might be exploited by an attacker with unprivileged access to an affected machine in order to escalate their privileges or gain access to data that they would otherwise be underprivileged to do so. 

Additionally, an attacker with code execution permissions on a container might exploit this vulnerability in order to gain access to data from other containers running on the same node. In multi-tenant containerized environments such as K8s, this might lead to unauthorized cross-tenant access. 

Since both these scenarios require an attacker to have existing access and local code execution privileges on an affected machine, patch rates are expected to be very swift, and cloud providers have mitigations in place to lower the impact of exploitation of this type of vulnerability, we rate this vulnerability as low severity in cloud environments.

Which products are affected? 

The flaw impacts all AMD CPUs built on the Zen 2 architecture, including: 

• Ryzen 3000 ("Matisse") 

• Ryzen 4000U/H ("Renoir")  

• Ryzen 5000U ("Lucienne") 

• Ryzen 7020 

• ThreadRipper 3000 

• Epyc server ("Rome") 

Note that this flaw is not dependent on any particular operating system. All operating systems are affected. 

In cloud environments, we estimate that the vast majority (if not all) potentially affected VM instances are running on “Rome”, which is a CPU designed for datacenters. In AWS, this includes C5a, C5ad, G4ad, and G5 EC2 instance types. In Azure, this includes HBv2, Da_v3 and Ea_v3 VMs. In GCP, this includes n2d-s2 (Rome), n2d-s4 (Rome) and n2d-s8 (Rome) VMs. 

GCP have posted a security bulletin stating that they have already patched all hosts against this issue. AWS has posted a security advisory stating they will deploy the patch once they have tested it (edit: AWS have since updated their advisory, mentioning that all hosts have been patched). In AWS, due to the Nitro System architecture, exploitation of the vulnerability on EC2 instances will provide the attacker with privileges only to the same EC2 instance. Azure and other cloud providers have not released security bulletins yet (as of the time of publication).

According to the disclosure timeline, AMD had released patches earlier than an agreed embargo date, which caused the researcher to disclose this issue earlier than planned, which likely caused AMD partners, such as the cloud providers, to be caught off guard in their patch planning for this (GCP were likely aware of this issue earlier than others, since the research was conducted within Google Project Zero, and therefore had more time to prepare). 

Which actions should security teams take? 

If your CPU is impacted by Zenbleed, it is recommended to apply AMD's new microcode update or wait for your computer vendor to incorporate the fix in a future BIOS upgrade. This is best handled by the Cloud Service Providers, but there are some mitigation steps that may be possible from within virtual machines. Note that applying the microcode update from within a VM has no effect, since it must be applied from the host (in the cloud, this is something that only the CSPs can do, not their customers). Similarly, applying the “chicken bit” mitigation (described in the vulnerability announcement as a potential workaround) is not technically possible from within a cloud-hosted VM instance. If you are using any of the abovementioned VM instance types in your cloud environment (except in GCP), you should identify all such instances and ensure they are otherwise secured until CSPs announce that microcode updates have been applied to the relevant instance types. 

For a given Linux VM, you can follow these steps to manually check if your host machine is affected by Zenbleed: 

First, run the following command to check your host’s CPU model, and then search online to see if this model uses the Zen 2 microarchitecture. If it does, then move on to the next step. Otherwise, your machine is not affected by Zenbleed. 

$ lscpu -J | grep 'Model name'

Next, to check if your machine is running on the latest microcode version, which is 0x0830107A (as of the date of publication), you can run the following command.  

 $ grep 'microcode' /proc/cpuinfo

Note that certain Linux distributions have published details for the microcode update packages and therefore the vulnerability might be detected on older versions of these packages. However, these can be considered false positives on VMs since the microcode patch would need to be applied from the host as mentioned above.  

Wiz customers can use the pre-built query and advisory in the Wiz Threat Center to search for vulnerable instances in their environment. 

References

• Tavis Ormandy blog

• AMD’s advisory

• GCP's bulletin

• AWS's advisory

• BleepingComputer article