Zenbleed CVE-2023-20593: What you need to know about the latest CPU vulnerability
If you woke up this week to news of a new CPU vulnerability affecting virtually everyone, you’re not alone. Named “Zenbleed” (CVE-2023-20593) by its reporter/discoverer Tavis Ormandy, this new vulnerability primarily targets AMD Zen CPUs and has the potential to cause substantial damage, much like previous CPU vulnerabilities such as Spectre and Meltdown.
What is Zenbleed and why should you care?
Zenbleed is an AMD Zen 2 CPU vulnerability allowing arbitrary reading of data from any cloud workload sharing the same CPU core. This includes virtual machines, containers, etc., regardless of the operating system in use.
The vulnerability isn’t environment-specific and could likely affect some cloud-based serverless workloads like AWS Lambda and Amazon EKS if they run on AMD Zen 2 CPUs. Moreover, this vulnerability doesn’t require elevated privileges for exploitation.
Though the system only leaks data during processing and an attacker cannot target or specify which data to read from areas sharing the same core, the impact can still be significant. If secrets (keys, passwords, hashes) are leaked, this could lead to unauthorized remote access.
While Zenbleed is relatively straightforward to exploit, its inherent characteristics potentially curtail its malicious applications. The inability to choose the data you wish to read potentially hampers its misuse by threat actors. We’ve discussed this extensively within the Lacework Cloud Threat Research team, arriving at a consensus that it’s unlikely to be effectively utilized by financially motivated threat actors.
However, the challenge lies in its detection. The complexity arises from the fact that the attacker doesn’t even need to be in the virtual machine to read its data; they can simply be on the host system. This property of Zenbleed allows it to circumvent traditional defenses. Consequently, our focus needs to remain on proactive mitigation and patching, given the stealthy nature of potential attacks.
To put this vulnerability into perspective, a Proof of Concept (POC) is available here. After a simple make command, you can run the created objects using ./zenbleed. Do note, however, that you will need the NASM compiler installed for this.
Zenbleed execution
Is Lacework vulnerable?
Addressing this vulnerability has been a top priority for our security team. As the Lacework platform included several instances using vulnerable AMD CPUs, we promptly moved all production services off of those vulnerable platforms. We are continuously monitoring for signs of attempted exploitation and will report any discoveries.
Identifying vulnerable machines with Lacework LQL query
To determine which machines in your environment are potentially vulnerable to Zenbleed, you can use a Lacework Query Language (LQL) query. LQL allows you to ask detailed questions about your cloud environment and security posture.
You can find a detailed guide on how to create an LQL query using the Lacework CLI here.
Alternatively, you can save the query below to a file (for example, zenbleed.yaml), and run the command:
lacework query run --start "-120d@d" --end "@h" -f zenbleed.yaml
Adjust the time period as needed.
Here is the LQL query to find potentially vulnerable machines.
As part of our commitment to safeguarding your environment, we have included a policy check for the Zenbleed vulnerability within the Lacework platform. The policy, named “Potential Zenbleed CPU Vulnerability“, has the ID “lacework-global-723”.
The most common vulnerable CPU models
From data analysis within our platform, we find that 12% of all instances monitored by Lacework use AMD CPUs. Of these, only 0.69% are vulnerable. Notably, while 52% of our customers currently use AMD machines in their environment, only 1% have vulnerable machines.
The five most common vulnerable CPU models found by our platform are:
- AMD Ryzen 9 3900 12-Core Processor
- AMD Ryzen 7 3700X 8-Core Processor
- AMD Ryzen 5 3600 6-Core Processor
- AMD Ryzen Threadripper 3960X 24-Core Processor
- AMD Ryzen Threadripper 3990X 64-Core Processor
Patches and mitigation steps
Zenbleed patches have been released by Ubuntu and AMD. Importantly, these patches need to be applied at the host machine level. Patching from within a VM or container would not suffice to protect against this vulnerability.
Google Cloud Platform (GCP) and Amazon Web Services (AWS) have already patched their systems. Other cloud service providers (CSPs), like Oracle, are expected to follow suit and patch their host systems soon.
What’s next?
We must closely monitor the implications of this vulnerability. While the full extent of Zenbleed’s exploitability is not yet fully understood, there exists a potential for misuse. This is particularly true given the vulnerability’s potential to be remotely triggered in various ways. For instance, if an underlying interpreter or web technology such as JavaScript or WebAssembly executes machine instructions that trigger the vulnerability. This was demonstrated in a Spectre proof-of-concept for web-based attacks and similarly highlighted by Derek Chamorro and Ignat Korchagin in Cloudflare’s blog post on Zenbleed.
In shared infrastructure environments like cloud service providers, vulnerabilities like these will always pose a concern. It’s crucial to understand the shared responsibility model in these scenarios.
For those interested in delving into the exploit’s source code, you can find it here.