Leaky Address Masking: Exploiting Unmasked Spectre Gadgets with Noncanonical Address Translation

Leaky Address Masking: Exploiting Unmasked Spectre Gadgets with Noncanonical Address Translation

Speakers: Mathé Hertogh, Sander Wiebing, Cristiano Giuffrida

Conference: IEEE S&P

YouTube: https://www.youtube.com/watch?v=MYfENN_JH3c

Overview

This talk, presented by Mathé Hertogh, Sander Wiebing, and Cristiano Giuffrida from VUsec, introduces a novel and concerning development in the landscape of speculative execution attacks, specifically Spectre. The research re-enables Spectre attacks via a new class of disclosure gadget, termed "unmasked gadgets," which were previously believed to be unexploitable. The core finding is the ability to achieve arbitrary ASCII data leakage, such as extracting the /etc/shadow file from the kernel, even from a user-space process. This is demonstrated not only on older generation AMD CPUs but, critically, the techniques developed primarily focus on bypassing architectural and microarchitectural protections on future generation Intel, AMD, and ARM CPUs.

The significance of this work stems from its challenge to the prevailing understanding of Spectre mitigations. While extensive efforts have been made to identify and eliminate "masked" disclosure gadgets—the traditional array-indexing patterns—the researchers reveal that "unmasked" pointer-chasing gadgets are far more prevalent in real-world code, with over 16,000 instances found in the Linux kernel alone. The paper details how to circumvent several key architectural defenses, including canonicity checks and Supervisor Mode Access Prevention (SMAP), by leveraging features like Intel's Linear Address Masking (LAM) and using the Translation Lookaside Buffer (TLB) as a covert channel. The implications are profound, suggesting a need for a fundamental re-evaluation of what constitutes a dangerous gadget and prompting a scramble for new mitigations even before the affected hardware is widely deployed.

Background

▶ Watch: Re-enabling Spectre with new unmasked disclosure gadgets (0:00)

The genesis of this research lies in the aftermath of the original Spectre vulnerabilities disclosed in early 2018. Classical Spectre attacks exploit speculative execution, a performance optimization where CPUs predict the outcome of branches and execute instructions ahead of time. If a prediction is wrong, the CPU discards the speculative state, but side effects, such as data being loaded into the cache, can persist and be observed by an attacker. In a typical Spectre scenario, a user-space attacker triggers the kernel to execute a mispredicted branch. The CPU then speculatively executes a snippet of code, often referred to as a disclosure gadget, chosen by the attacker. This gadget accesses secret data and encodes it into a microarchitectural side channel, such as the data cache, allowing the attacker to infer the secret.

The prototypical disclosure gadget, as found in the original Spectre paper, involves double array indexing. Here, a secret value S is loaded, then masked (e.g., S & 0xFF), and used as an index into an attacker-controlled array (array[secret_byte page_size]). The resulting cache line access creates a timing difference observable by the attacker. Following the discovery of Spectre, extensive efforts were undertaken by developers, including those for the Linux kernel, to identify and remove these "masked" gadgets. For instance, approximately 250 such gadgets were found and mitigated in the Linux kernel, a seemingly manageable number given its vast codebase. The security of these mitigations crucially relies on the ability to accurately identify all* possible disclosure gadget patterns.

However, the talk highlights a different class of gadget: unmasked gadgets. Instead of masking a secret and using it as an array index, these gadgets directly interpret a full 64-bit secret as a pointer and dereference it. An example from Linux kernel 6.3 provided in the talk shows a function where a pointer to a structure is dereferenced to obtain a member F, which is then itself interpreted as a pointer and dereferenced again. Previous analysis, including by Intel engineers, explicitly discarded these pointer-chasing patterns as non-exploitable due to several inherent challenges, such as the large entropy of a 64-bit secret, the requirement for canonical addresses, and the SMAP mitigation. This prior belief forms the critical baseline that the researchers challenge and overturn. Their gadget scanner revealed a staggering prevalence of these unmasked patterns, identifying over 16,000 such double pointer dereference gadgets in the Linux kernel, making their potential exploitability a far greater concern than the original masked variants.

Key Findings

▶ Watch: 16,000+ unmasked pointer-chasing gadgets found in Linux kernel (4:00)

The central and most significant finding of this research is the demonstration that unmasked Spectre gadgets, previously considered unexploitable, can indeed be leveraged to achieve arbitrary data leakage from the kernel. This directly contradicts earlier analyses and fundamentally alters the understanding of Spectre's attack surface. Instead of merely breaking Kernel Address Space Layout Randomization (KASLR) by leaking valid kernel pointers, the researchers show how to extract arbitrary ASCII data, exemplified by the /etc/shadow file.

The exploit, dubbed SLAM (Spectre based on Linear Address Masking), overcomes three major architectural and microarchitectural hurdles that previously protected against unmasked gadget exploitation:

1. Bypassing Canonicity Checks: Virtual addresses on x86-64 architectures are typically canonical, meaning their most significant bits must either all be zero or all be one. If a 64-bit secret happens to encode a non-canonical address, the CPU will fault, preventing speculative execution from proceeding. The researchers demonstrate how upcoming CPU features like Intel's Linear Address Masking (LAM), ARM's Top Byte Ignore (TBI), and AMD's Upper Address Ignore (UAI) can be abused to bypass these checks, as these features allow software to place arbitrary data in the high bits of pointers, effectively relaxing the canonicity requirements. For older AMD CPUs, a microarchitectural race condition is employed.

1. Bypassing Supervisor Mode Access Prevention (SMAP): SMAP is a critical mitigation designed to prevent kernel code from accidentally or maliciously accessing user-space memory, even speculatively. If a secret value, when interpreted as an address, falls within user-space memory, SMAP would typically prevent any data from being loaded into the cache, thus thwarting a cache-based side channel. The key insight here is that SMAP checks are performed after address translation. By using the Translation Lookaside Buffer (TLB) as a covert channel instead of the data cache, the researchers show that even if SMAP prevents data from entering the cache, the speculative address translation will still populate the TLB, leaving an observable side effect.

1. Overcoming 64-bit Entropy: A full 64-bit secret presents an impossibly large search space for a side-channel attack. Even after accounting for LAM (which ignores some high bits) and the TLB's page granularity (which ignores page offset bits), a significant number of bits (e.g., 36 bits) of entropy remain. The solution involves an iterative, byte-by-byte leakage strategy. By assuming partial knowledge of the target data (e.g., knowing the beginning of a file like /etc/shadow), the attacker can focus on leaking a single unknown byte. This is achieved by mapping 128 user pages corresponding to all possible ASCII byte values, triggering the gadget, and then measuring TLB access times to identify which page was speculatively accessed.

These findings collectively demonstrate a sophisticated new attack vector that renders a vast class of previously ignored Spectre gadgets exploitable, highlighting a critical gap in current mitigation strategies, especially for next-generation CPU architectures.

Technical Deep Dive

▶ Watch: Challenges: 64-bit secret, canonicality, SMAP, unmapped memory (6:00)

The technical core of the SLAM exploit lies in its elegant circumvention of several hardware and software defenses designed to prevent speculative execution attacks. To understand this, it's crucial to contrast masked and unmasked gadgets and then delve into the specific bypass techniques.

Masked vs. Unmasked Gadgets

Classical Masked Gadgets:

These are the original "disclosure gadgets" that formed the basis of early Spectre attacks. In a masked gadget, a secret value S is loaded from kernel memory. A specific portion of this secret (e.g., a single byte) is then extracted or "masked" (e.g., (S >> shift) & 0xFF). This masked byte is then used as an index into an attacker-controlled array, typically multiplied by the page size (array[masked_byte PAGE_SIZE]). The speculative access to array[X] brings a specific cache line into the CPU's data cache. By subsequently measuring access times to all possible array locations, the attacker can infer the value of X, and thus the masked byte of the secret. The key here is the masking* operation, which reduces the secret's entropy to a manageable 8 bits, allowing it to map to a feasible number of cache lines (256).

Unmasked Gadgets:

In contrast, unmasked gadgets directly interpret the full 64-bit secret S as a pointer and immediately dereference it (*S). There is no masking, shifting, or multiplication. This direct dereference presents significant challenges:

1. 64-bit Entropy: The secret can be any 64-bit value, which is far too large to map to a cache-based covert channel directly. A cache with 2^64 lines is physically impossible.
2. Canonicity: On x86-64, virtual addresses must be canonical. This means bits 63 through 48 must all be either zero or one, mirroring bit 47. If the 64-bit secret happens to encode a non-canonical address, the CPU will raise a fault, preventing any speculative memory access.
3. SMAP Mitigation: If the secret, when interpreted as an address, points to a user-space memory location, the Supervisor Mode Access Prevention (SMAP) feature would prevent the kernel (even speculatively) from loading data from that address into the data cache. This is a critical defense against kernel-to-user data leakage.

The SLAM exploit systematically addresses these three challenges.

Bypassing Canonicity Checks with Linear Address Masking (LAM)

The canonicity problem is a major hurdle for unmasked gadgets. If the raw 64-bit secret has a mix of zeros and ones in its upper bits (e.g., bits 48-63), the CPU will treat it as an invalid address.

The researchers leverage upcoming CPU features to bypass this. Intel's Linear Address Masking (LAM), ARM's Top Byte Ignore (TBI), and AMD's Upper Address Ignore (UAI) are designed to allow software to store metadata in the high bits of virtual addresses without interfering with address translation. With LAM, for example, the CPU is configured to ignore a range of high bits (e.g., 15 bits). The canonicity check is then reduced to ensuring bit 63 and bit 47 are equal.

Crucially for arbitrary ASCII data leakage, ASCII characters are encoded using only 7 bits, meaning the most significant bit of every byte is always zero. When multiple ASCII bytes are concatenated to form a 64-bit value, the top bit of each byte will be zero. This means that if the secret is ASCII data, both bit 63 and bit 47 will naturally be zero, thus successfully bypassing the relaxed canonicity check enabled by LAM. This makes ASCII data a prime target for this attack.

For older AMD CPUs that do not yet have UAI, the paper mentions using a microarchitectural race condition to achieve a similar canonicity bypass, though details are relegated to the full paper.

Bypassing SMAP with TLB as a Covert Channel

SMAP is a powerful mitigation. When the CPU is in kernel mode, SMAP prevents speculative loads from user-space memory into the data cache. Since ASCII data, when interpreted as an address, often falls into the user-space address range (typically addresses with bit 47 set to 0), SMAP would prevent a traditional data cache covert channel.

The critical insight here is the timing of the SMAP check: it occurs after address translation. When an unmasked gadget speculatively dereferences a secret that looks like a user-space address, the CPU first performs the virtual-to-physical address translation. If the page table entry indicates a user page and the address is backed by physical memory, this translation process will populate an entry in the Translation Lookaside Buffer (TLB). Only then does the SMAP check kick in and prevent the actual data load into the data cache.

Therefore, even if the data cache remains unaffected, the TLB state does change. The TLB becomes the new covert channel. By ensuring the attacker has mapped user-space memory at the target virtual address (corresponding to the secret byte), the speculative dereference will cause a TLB hit for that address. The attacker can then measure TLB access times to infer which address was speculatively translated.

Overcoming 64-bit Entropy

Even with LAM bypassing canonicity and the TLB bypassing SMAP, a significant challenge remains: the sheer size of the secret. After LAM ignores some high bits and the TLB's page granularity ignores the page offset bits (typically 12 bits for a 4KB page), there can still be 36 bits of entropy to leak (e.g., on a system with 48-bit virtual addresses and 15 LAM bits). This is still too much for a practical side-channel attack.

The solution involves an iterative, byte-by-byte leakage strategy, assuming partial knowledge of the target secret. For example, if the goal is to leak the /etc/shadow file, the attacker might know it typically starts with "root:". This known prefix helps narrow down the target.

The process for leaking a single unknown byte (e.g., the byte after "root:") is as follows:

1. Map Pages: The attacker maps 128 user-space pages, each corresponding to a possible ASCII byte value (0x00 to 0x7F). These pages are strategically located in the virtual address space so that when combined with the known prefix and the page offset bits (which are ignored by the TLB), they form unique virtual addresses that differ only by the target byte.
2. Evict TLB: The attacker ensures that none of these 128 mapped pages are currently in the TLB.
3. Trigger Gadget: The attacker triggers the kernel to speculatively execute the unmasked gadget. The gadget dereferences the secret, which now includes the target unknown byte.
4. Populate TLB: Due to the speculative dereference, the virtual address corresponding to the correct secret byte will be translated, and its corresponding entry will be inserted into the TLB.
5. Measure TLB: The attacker then measures the access times to all 128 mapped pages. The page that was speculatively inserted into the TLB will show a significantly lower access time (a "hit") compared to the others (a "miss").
6. Leak Byte: By identifying the page with the hit, the attacker reveals the value of the unknown byte.
7. Iterate: This process is repeated for subsequent bytes, gradually reconstructing the entire secret.

This iterative approach, combined with the LAM bypass and TLB covert channel, forms the complete SLAM exploit, enabling arbitrary ASCII data leakage from the kernel.

Demo / Proof of Concept

▶ Watch: Roadmap to arbitrary ASCII data leakage (8:00)

The talk culminates in the demonstration of the SLAM (Spectre based on Linear Address Masking) exploit. This proof of concept successfully leverages the techniques detailed in the technical deep dive to achieve practical data leakage.

The researchers implemented SLAM to leak the contents of the /etc/shadow file from an up-to-date Linux system. This file is highly sensitive, containing hashed passwords and other critical user authentication information. The exploit was shown to complete "within minutes," demonstrating its practical viability and efficiency.

Crucially, the SLAM exploit was not dependent on a single, isolated gadget. The researchers confirmed its applicability across multiple instances, stating that they successfully exploited "seven gadgets" in the Linux kernel. This highlights that the attack is not a niche theoretical exploit but rather a widespread vulnerability, given the prevalence of these unmasked pointer-chasing patterns (over 16,000 identified in Linux kernel 6.3). The successful exploitation of multiple real-world gadgets underscores the broad impact of this new attack vector and the urgent need for comprehensive mitigations.

Defensive Implications

▶ Watch: Bypassing canonicality using Linear Address Masking (LAM) (9:00)

The discovery and exploitation of unmasked Spectre gadgets with noncanonical address translation have significant and immediate defensive implications, particularly for future CPU architectures. The researchers' proactive approach in targeting upcoming CPU features means that mitigations can potentially be deployed before these chips reach widespread production, a rare and valuable opportunity in security.

1. Re-evaluation of Disclosure Gadgets: The most fundamental implication is the need to redefine what constitutes a "disclosure gadget." The prior assumption that unmasked, pointer-chasing patterns were unexploitable has been definitively overturned. Defenders, especially kernel developers and compiler writers, must now scan for and mitigate these far more prevalent gadgets (over 16,000 in Linux kernel 6.3) in addition to the classical masked variants.

1. Intel's Response and LASS: Intel has acknowledged the findings and is planning a mitigation called Linear Address Space Separation (LASS). In essence, LASS strengthens the existing SMAP mitigation. While SMAP traditionally checks for user/kernel page status after address translation, LASS aims to make this check occur before address translation. This would prevent the TLB from being speculatively populated with user-space addresses from kernel mode, thus neutralizing the TLB covert channel used by SLAM. The Linux kernel developers are consequently preparing to prevent users from enabling LAM on future Intel systems unless LASS is also enabled, ensuring that the LAM feature doesn't inadvertently open a new attack surface.

1. ARM's Guidance: ARM has also updated its guidance in response to this research. They have released a white paper discussing the attack's implications, particularly concerning future ARM CPUs that might implement five-level paging and features similar to LAM (like TBI). This indicates a proactive stance in addressing potential vulnerabilities in their upcoming architectures.

1. AMD's Stance: Notably, the researchers stated that AMD "did not plan on any new mitigations" in response to this specific attack. This is a critical detail, suggesting that future AMD CPUs might remain vulnerable to SLAM-like attacks unless their stance changes or other software-level mitigations are widely adopted. This highlights a potential divergence in security posture among major CPU vendors.

1. Software-level Hardening: Beyond hardware changes, software developers must consider:

• Compiler-based Mitigations: Compilers could be enhanced to detect and transform unmasked pointer dereferences in sensitive kernel code, for example, by inserting speculative execution barriers (e.g., LFENCE) or by ensuring that critical pointers are always canonical and within expected ranges, even when used speculatively.
• Kernel Hardening: Kernel developers might need to implement more robust strategies for isolating sensitive data or ensure that all speculative loads are non-observable via side channels. The sheer number of identified unmasked gadgets makes manual patching impractical, necessitating systemic solutions.

In summary, the research demands a paradigm shift in how speculative execution vulnerabilities are understood and mitigated. It emphasizes the importance of a holistic approach, considering both hardware features and software implementations, to secure systems against these sophisticated microarchitectural attacks.

Key Takeaways

• Unmasked Spectre Gadgets are Exploitable: Contrary to previous beliefs, double pointer dereference ("unmasked") Spectre gadgets can be exploited to leak arbitrary data from the kernel.
• Widespread Vulnerability: These unmasked gadgets are far more prevalent than classical masked gadgets, with over 16,000 instances found in Linux kernel 6.3.
• Future CPU Features Enable Attacks: Upcoming features like Intel's Linear Address Masking (LAM), ARM's Top Byte Ignore (TBI), and AMD's Upper Address Ignore (UAI) can be abused to bypass canonicity checks, especially for ASCII data.
• TLB as a Covert Channel: The Translation Lookaside Buffer (TLB) can be used as a covert channel to bypass the SMAP mitigation, as speculative address translations populate the TLB even if data caching is prevented.
• SLAM Exploit Achieves Arbitrary Leakage: The SLAM (Spectre based on Linear Address Masking) exploit demonstrates practical, byte-by-byte arbitrary ASCII data leakage, exemplified by extracting the /etc/shadow file from a running Linux kernel within minutes.
• Varied Mitigation Responses: Intel and ARM are developing or have issued guidance for new mitigations (e.g., LASS for Intel), while AMD reportedly has no new mitigations planned for this specific attack.

About the Speaker(s)

The talk was presented by Mathé Hertogh, Sander Wiebing, and Cristiano Giuffrida. All three researchers are affiliated with VUsec, the Systems and Network Security Group at the Vrije Universiteit Amsterdam (VU Amsterdam). VUsec is a renowned research group known for its significant contributions to system security, particularly in areas like microarchitectural attacks, operating system security, and virtualization security. Their work frequently uncovers fundamental vulnerabilities in modern computing systems and drives the development of new defensive mechanisms.