AMD Zenbleed Vulnerability Exposed: What You Need to Know Now

Recently, a new vulnerability was discovered that affects some AMD processors and can allow an attacker to potentially gather massive chunks of private data. How exactly does this attack work, why are speculative systems causing trouble in the security world, and is there anything that engineers can do about this?

Zenbleed – A New Speculative Attack

A new vulnerability affecting AMD Ryzen and Epyc Zen 2 chips was recently announced to the public, sparking a flurry of countermeasures from numerous companies that may be at risk. The new vulnerability, called Zenbleed, allows an attacker to extract potentially private data at a rate of 30Kb per core per second, which may not sound fast at first, but considering that 30Kb can easily hold cryptographic keys, usernames and other credentials, it presents a very serious threat. 

To make matters worse, the new vulnerability is not only exploitable via standard applications with no elevated privileges but also via malicious webpages where executed JavaScript can access speculative data. This means that unsuspecting users can be directed to an infected page, have data stolen, and be entirely unaware of the theft going on (especially with the low data rate from the vulnerability). 

Luckily, the vulnerability can be fixed via a microcode fix, and AMD is now actively working to make users aware of the situation, urging those affected by Zenbleed to perform an update. But how exactly does the exploit work?

Understanding the Zenbleed Exploit

Zenbleed takes advantage of speculative execution, whereby a CPU will speculate on what it will need to execute in the future to improve performance drastically. In the case that the speculative event was true, the results are instantly delivered, but if the speculative event was false, then the results are discarded with no harm done.

However, if a user’s program wants to access a private area of memory (such as the contents of RAM from another application), the CPU will reject this request, but speculative engines can actually execute this request regardless of permissions. Now, if the event is true, the CPUs security controls will not allow access to the data that was speculatively obtained, but registers used by that speculation may be left unaltered, potentially exposing data.

In the case of Zenbleed, the vulnerability takes advantage of the vzeroupper instruction that, instead of actually clearing a register’s value to zero, sets a bit, indicating that it was cleared in software and then allows other applications to take advantage of those registers. This instruction is used by numerous libraries and functions, including the all famous str_len(). 

The trouble with this instruction is that if it is speculatively executed, other programs can utilise the register and place data into the register. If the CPU then realises that this speculation should not have happened, it resets the zero bit, but the data in that register persists. As such, the attacker can then take the content of that register and reattempt the speculative execution. Furthermore, the zero bit can be used to indicate a successful attack, accelerating the speed at which data is extracted.

The Zenbleed vulnerability is filed as CVE-2023-20593 and allows data exfiltration at a rate of 30kb per core, per second. The attack works by manipulating the register files to force a mispredicted command, exploiting the speculative execution engine. AMD describes the exploit more simply, stating, "Under specific microarchitectural circumstances, a register in “Zen 2” CPUs may not be written to 0 correctly. This may cause data from another process and/or thread to be stored in the YMM register, which may allow an attacker to potentially access sensitive information." Read the full technical rundown here.

Why are speculative systems causing trouble in security?

While speculative systems in modern CPUs do indeed provide massive performance boosts, they are starting to cause headaches for those involved with security. By speculatively executing code without checking whether that execution would be allowed in the first place means that processors potentially expose data placed into registers and memory.

But Zenbleed is not the first vulnerability to exploit speculative execution; Spectre was a very famous vulnerability that was shown to affect most microprocessors developed by Intel prior to 2020. Another exploit was Meltdown which, too, took advantage of a race condition between speculative execution and privilege checking, again allowing attackers to access potentially private data.

The real headache behind these attacks comes down to whether the microcode or silicon is at fault. If the problem lies in the CPU microcode, then updates can be provided that help to get around the issue, thereby giving security teams the opportunity to protect hardware. If, instead, the problem lies in the physical silicon itself, then no number of updates will prevent an attack from being executed (as was the case in Spectre).

What can engineers do in such situations?

Unfortunately, there is very little that engineers can do when faced with speculative vulnerabilities except for how the problem lies in the microcode. If, however, the physical processor in a design can be replaced (such as a socketed part), then it should be replaced as early as possible. Of course, this is not always possible for some designs, especially for large-scale machines such as server farms and supercomputers, where the cost would be exceedingly high.

With regards to those designing CPUs with speculative execution, it is very difficult to solve such challenges as they are typically hard to predict, and microcode for modern CPUs is unbelievably complex (that doesn’t even include the hardware). Moving forward, mechanisms that check a speculative privilege level should be incorporated, which outright shutdown attempts from non-privileged code. But this is easier said than done, and trying to add extra layers on top of speculative execution runs the risk of reducing CPU performance. 

Tavis Ormandy, a researcher with Google Information Security, discovered the Zenbleed vulnerability, officially known as CVE-2023-20593, which affects all Zen 2 class processors. The vulnerability is rooted in the incorrect recovery from a mispredicted vzeroupper instruction, allowing an attacker to spy on operations like strlen, memcpy, and strcmp happening anywhere on the system. Ormandy's research reveals that the bug can be triggered through precise scheduling, and he even developed an exploit that can leak about 30 kb per core, per second.

AMD has released a microcode update to address the issue, and a software workaround is also available. The Zenbleed vulnerability highlights the delicate balance between performance and security in modern processors, serving as a reminder that constant vigilance and collaboration between hardware manufacturers and the cybersecurity community are essential.

Overall, the Zenbleed vulnerability certainly presents security challenges to millions of systems currently in use, and updates to these devices must be made. 

Mitigation Strategies for Zenbleed

Addressing the Zenbleed vulnerability requires a multi-faceted approach. AMD has released a microcode update that users should apply promptly. Additionally, organisations should consider the following strategies:

• Regularly update all software and firmware to ensure the latest security patches are applied.
• Monitor systems for unusual activity that may indicate an attempted exploitation of the vulnerability.
• Educate users about the risks of malicious webpages and promote safe browsing habits.

By taking a proactive and comprehensive approach to security, organisations can minimise the risks associated with Zenbleed and other speculative execution vulnerabilities.

The Zenbleed vulnerability serves as a critical reminder of the evolving landscape of cybersecurity. Staying informed and taking decisive action is key to safeguarding systems and data. For more information on Zenbleed and to access the latest updates, visit AMD's official website or consult with a cybersecurity professional.

Glossary

• Speculative Execution: A process where a CPU predicts and executes instructions that might be needed in the future to improve performance.
• Microcode: A layer of hardware-level instructions that control the CPU's core operations.
• Vzeroupper Instruction: A specific command used in CPU operations to clear certain register values.

Conclusion

The Zenbleed vulnerability underscores the complex interplay between performance and security in modern processors. By understanding the technical aspects of this vulnerability and implementing the recommended mitigation strategies, organisations can protect their systems and data. The evolving landscape of cybersecurity requires constant vigilance, collaboration, and adaptation. The Zenbleed case serves as a critical reminder of these imperatives, reinforcing the need for proactive measures in an increasingly interconnected world.