Researchers Discovered Novel Way to Extract Secrets From Intel and AMD Chips

Last updated September 23, 2021

Written by:

Bill Toulas
Cybersecurity Journalist

A team of university researchers has developed attack methods that can leak info from the micro-op cache.
This is taking place before the speculative execution step, so all Spectre mitigations are essentially bypassed.
Seeing this fixed or even lightly mitigated is highly unlikely, as the risks of exploitation are mostly theoretical.

A team of researchers from the University of Virginia and the University of California, San Diego, has discovered a way to extract “secrets” from the micro-op cache inside Intel and AMD processors while bypassing all Spectre protections that have been incorporated over the years. The boffins have reverse-engineered many undocumented features of the internal micro-ops used in modern chips and managed to develop three attack methods that would result in stealthy data leaks.

First, there’s a cross-domain attack that takes place across the user-kernel boundary. The second is a cross-SMT thread attack that transmits secret data across two SMT threads via the micro-op cache. And the third is a transient execution attack that leaks secrets that are accessed along a misspeculated path, which is where the Spectre mitigations are bypassed.

To put this simply, micro-op caches are an internal place in the processor where sensitive information is stored temporarily before execution, awaiting security checks. This was added onto modern chips to improve their performance, as the micro-op cache holds small instruction chunks that can help speed up speculative execution. Specter attacks disrupted that last step and gained access by diverting the instructions to a different path. In this latest discovery, the data disruption happens before the instructions are approved for entering speculative execution, so it is very effective even if inevitably not as useful.

The researchers suggest a couple of potential mitigations, like flushing the micro-op cache at domain crossings, performing counter-based monitoring, or introducing privilege level-based partitioning. As it’s always the case with attacks of this kind, fixing them isn’t simple at all because the flaws are intrinsic to the chip’s operation and design. Sure, disabling speculative execution would address everything, but the drop in performance would be very noticeable, and the risk that will be addressed as a result isn’t that severe.

These attack methods aren’t easy to weaponize or to exploit in a meaningful way, even if they theoretically affect billions of systems out there. From what we understand, this discovery concerns all x86 chips made after 2011, although the researchers focused on Intel Skylake and AMD Zen microarchitectures in their study. Due to the scope and the balance between security gains and performance losses, we wouldn’t expect to see an aggressive response to this discovery by Intel or AMD. Still, the paper offers an interesting perspective for chip engineers to consider in the future nonetheless.

Update May 4, 2021

Intel has reached out to inform us that the attack methods described in the paper have already been mitigated for developers who are following the company's guidance. Here's the statement they have shared:

INTEL REVIEWED THE REPORT AND INFORMED RESEARCHERS THAT EXISTING MITIGATIONS WERE NOT BEING BYPASSED AND THAT THIS SCENARIO IS ADDRESSED IN OUR SECURE CODING GUIDANCE. SOFTWARE FOLLOWING OUR GUIDANCE ALREADY HAVE PROTECTIONS AGAINST INCIDENTAL CHANNELS INCLUDING THE UOP CACHE INCIDENTAL CHANNEL. NO NEW MITIGATIONS OR GUIDANCE ARE NEEDED.

Update May 5, 2021

Response from Ashish Venkat, William Wulf Career Enhancement Assistant Professor of Computer Science at the University of Virginia School of Engineering:

We're aware of these guidelines from Intel suggesting software developers to write code in a way that is not vulnerable to side-channel attacks. Here's an excerpt from the Intel article –'Developers who wish to protect secret data against timing side channel methods should ensure that their code runtime, data access patterns, and code access patterns are identical independent of secret values.’

Certainly, we agree that software needs to be more secure, and we agree as a community that constant-time programming is an effective means to writing code that is invulnerable to side-channel attacks. However, the vulnerability we uncover is in hardware, and it is important to also design processors that are secure and resilient against these attacks.

In addition, constant-time programming is not only hard in terms of the actual programmer effort but also entails high performance overhead and significant deployment challenges related to patching all sensitive software. The percentage of code that is written using Constant Time principles is, in fact, quite small. Relying on this would be dangerous. That is why we still need to secure the hardware.