Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Oreo: Protecting ASLR Against Microarchitectural Attacks (Extended Version)

Shixin Song, Joseph Zhang, Mengjia Yan

TL;DR

ASLR is widely used but vulnerable to microarchitectural side channels. Oreo presents a software–hardware co-design that inserts a masked address layer between virtual and physical memory, ensuring microarchitectural structures index using protected, secret-free addresses and that the architectural state is only checked at commit time. The approach blocks the first two ASLR leakage paths, with a formal non-interference proof and a Linux/gem5 prototype showing negligible overhead on SPEC 2017 and near-zero latency impact on kernel/system calls. The work demonstrates practical feasibility for hardening memory layouts against current and potential microarchitectural attacks, while acknowledging a security dilemma with speculative gadgets and outlining future enhancements like page-granularity ASLR.

Abstract

Address Space Layout Randomization (ASLR) is one of the most prominently deployed mitigations against memory corruption attacks. ASLR randomly shuffles program virtual addresses to prevent attackers from knowing the location of program contents in memory. Microarchitectural side channels have been shown to defeat ASLR through various hardware mechanisms. We systematically analyze existing microarchitectural attacks and identify multiple leakage paths. Given the vast attack surface exposed by ASLR, it is challenging to effectively prevent leaking the ASLR secret against microarchitectural attacks. Motivated by this, we present Oreo, a software-hardware co-design mitigation that strengthens ASLR against these attacks. Oreo uses a new memory mapping interface to remove secret randomized bits in virtual addresses before translating them to their corresponding physical addresses. This extra step hides randomized virtual addresses from microarchitecture structures, preventing side channels from leaking ASLR secrets. Oreo is transparent to user programs and incurs low overhead. We prototyped and evaluated our design on Linux using the hardware simulator gem5.

Oreo: Protecting ASLR Against Microarchitectural Attacks (Extended Version)

TL;DR

ASLR is widely used but vulnerable to microarchitectural side channels. Oreo presents a software–hardware co-design that inserts a masked address layer between virtual and physical memory, ensuring microarchitectural structures index using protected, secret-free addresses and that the architectural state is only checked at commit time. The approach blocks the first two ASLR leakage paths, with a formal non-interference proof and a Linux/gem5 prototype showing negligible overhead on SPEC 2017 and near-zero latency impact on kernel/system calls. The work demonstrates practical feasibility for hardening memory layouts against current and potential microarchitectural attacks, while acknowledging a security dilemma with speculative gadgets and outlining future enhancements like page-granularity ASLR.

Abstract

Address Space Layout Randomization (ASLR) is one of the most prominently deployed mitigations against memory corruption attacks. ASLR randomly shuffles program virtual addresses to prevent attackers from knowing the location of program contents in memory. Microarchitectural side channels have been shown to defeat ASLR through various hardware mechanisms. We systematically analyze existing microarchitectural attacks and identify multiple leakage paths. Given the vast attack surface exposed by ASLR, it is challenging to effectively prevent leaking the ASLR secret against microarchitectural attacks. Motivated by this, we present Oreo, a software-hardware co-design mitigation that strengthens ASLR against these attacks. Oreo uses a new memory mapping interface to remove secret randomized bits in virtual addresses before translating them to their corresponding physical addresses. This extra step hides randomized virtual addresses from microarchitecture structures, preventing side channels from leaking ASLR secrets. Oreo is transparent to user programs and incurs low overhead. We prototyped and evaluated our design on Linux using the hardware simulator gem5.

Paper Structure

This paper contains 45 sections, 4 theorems, 8 equations, 12 figures, 1 table.

Table of Contents

  1. Introduction
  2. Background
  3. Address Space Layout Randomization
  4. Virtual Memory Systems
  5. Microarchitectural Side Channel Attacks
  6. Understanding ASLR Bypasses Using Microarchitectural Attacks
  7. Threat Model
  8. Design of Oreo
  9. Overview
  10. Protecting Microarchitecture Oblivious Bits
  11. Choosing Bits to Protect
  12. Further Increasing Entropy of Oreo-Protected Bits
  13. Limitations
  14. Implementation Details
  15. Software Changes
  16. ...and 30 more sections

Key Result

Lemma 1

For all $L$, $L'\!\in\! \mathcal{L}_{\emph{Oreo}\xspace}$, $P$, $S\!=\!\mathop{\texttt{Init}}_{\emph{Oreo}\xspace}(P, L)$, and $S'\!=\!\mathop{\texttt{Init}}_{\emph{Oreo}\xspace}(P,L')$,

Figures (12)

  • Figure 1: Overview of Oreo's new memory interface
  • Figure 2: Coarse-grained ASLR. (a) shows the whole virtual address space with multiple randomization regions. (b) and (c) show memory content is loaded using a public offset when ASLR is disabled and a private offset when ASLR is enabled.
  • Figure 3: Three leakage paths that leak ASLR secret offset
  • Figure 4: Mapping between a virtual address $v$ and a masked address $w$ using Oreo's memory interface.
  • Figure 5: Protected bits selection strategies and their corresponding entropy. "Remaining entropy*" refers to "remaining entropy after ASLR bypasses using the first two leakage paths"
  • ...and 7 more figures

Theorems & Definitions (10)

  • Definition 1: $\mathop{\texttt{Req}} (S, t)\!=_{func}\!\mathop{\texttt{Req}}(S',t)$
  • Definition 2: $\mathop{\texttt{Req}}(S, t)\!=_{mask}\! \mathop{\texttt{Req}}(S', t)$
  • Lemma 1
  • proof
  • Lemma 2
  • proof
  • Definition 3: $S\!=_{\mathrm{pub}}\! S'$
  • Lemma 3
  • proof
  • Theorem 1