RetSpill: Igniting User-Controlled Data to Burn Away Linux Kernel Protections

RetSpill: Igniting User-Controlled Data to Burn Away Linux
Kernel Protections
Kyle Zeng
Arizona State University
zengyhkyle@asu.edu
Zhenpeng Lin
Northwestern University
zplin@u.northwestern.edu
Kangjie Lu
University of Minnesota
kjlu@umn.edu
Xinyu Xing
Northwestern University
xinyu.xing@northwestern.edu
Ruoyu Wang
Arizona State University
fishw@asu.edu
Adam Doupé
Arizona State University
doupe@asu.edu
Yan Shoshitaishvili
Arizona State University
yans@asu.edu
Tiffany Bao
Arizona State University
tbao@asu.edu
ABSTRACT
Leveraging a control flow hijacking primitive (CFHP) to gain root
privileges is critical to attackers striving to exploit Linux kernel vul-
nerabilities. Such attack has become increasingly elusive as security
researchers propose capable kernel security mitigations, leading to
the development of complex (and, as a trade-off, brittle and unreli-
able) attack techniques to regain it. In this paper, we obviate the
need for complexity by proposing RetSpill, a powerful yet elegant
exploitation technique that employs user space data already present
on the kernel stack for privilege escalation.
RetSpill exploits the common practice of temporarily storing
data on the kernel stack, such as when preserving user space regis-
ter values during a switch from the user space to the kernel space.
We perform a systematic study and identify four common practices
that spill user space data to the kernel stack. Although this practice
is perfectly within the kernel’s security specification, it introduces
a new exploitation path when paired with a control flow hijacking
(CFH) vulnerability, enabling RetSpill to turn such vulnerabilities
directly into privilege escalation reliably. Moreover, RetSpill can
bypass many defenses currently deployed in the Linux kernels. To
demonstrate the severity of this problem, we collected 22 real-world
kernel vulnerabilities and built a semi-automated tool that abuses
intentionally-stored, on-stack user space data for kernel exploita-
tion in a semi-automated fashion. Our tool generated end-to-end
privilege escalation exploits for 20 out of 22 CFH vulnerabilities.
Finally, we propose a new mechanism to defend against the attack.
CCS CONCEPTS
• Security and privacy → Operating systems security; Software
security engineering.
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org.
CCS ’23, November 26–30, 2023, Copenhagen, Denmark
© 2023 Copyright held by the owner/author(s). Publication rights licensed to ACM.
ACM ISBN 979-8-4007-0050-7/23/11. . . $15.00
https://doi.org/10.1145/3576915.3623220
KEYWORDS
OS Security; Kernel Exploitation; Privilege Escalation
ACM Reference Format:
Kyle Zeng, Zhenpeng Lin, Kangjie Lu, Xinyu Xing, Ruoyu Wang, Adam
Doupé, Yan Shoshitaishvili, and Tiffany Bao. 2023. RetSpill: Igniting User-
Controlled Data to Burn Away Linux Kernel Protections. In Proceedings of
the 2023 ACM SIGSAC Conference on Computer and Communications Security
(CCS ’23), November 26–30, 2023, Copenhagen, Denmark. ACM, New York,
NY, USA, 15 pages. https://doi.org/10.1145/3576915.3623220
1
INTRODUCTION
As Linux becomes increasingly ubiquitous in cloud services, IoT
devices, and mobile phones
1
, Linux kernel vulnerabilities have
emerged to be a major threat to computer security. The successful
exploitation of a Linux kernel vulnerability can allow attackers to
elevate privileges and induce critical issues in victim systems.
Among Linux kernel vulnerabilities, those giving attackers the
ability to carry out Control Flow Hijack (CFH) is a prevalent and se-
rious type of flaw. Attackers exploit such vulnerabilities to achieve
control flow hijacking primitives (CFHP) (e.g., by overwriting a func-
tion pointer stored in the kernel heap), then use creative techniques
to bypass modern defenses (e.g., SMAP) before finally escalating
the attacker’s privilege level from normal users to root. CFH is pop-
ularly used for Linux kernel exploitation despite modern defenses.
For example, 15 out of 16 public real-world Linux kernel exploits
[23] reported to 2022 Google’s kCTF kernel bug bounty program
are control-flow hijacking attacks.
However, there is a significant gap from CFHP to a full kernel
privilege escalation exploit. In most modern cases, CFHP stems
from flaws on the heap (e.g., a function pointer overwrite stemming
from a use-after-free), instead of the stack. This is problematic
for exploitation, as building and triggering an ROP payload on
the heap is hard. Current solutions to this problem attempt to
pivot the stack pointer to a fake stack on the heap [19, 29, 46]
or in the flat physical mapping [70]. Such techniques are brittle
because they rely on either specific kernel memory layouts, the
existence of precise bespoke gadgets, or additional primitives (such
as register control) that are not always granted alongside the CFHP.
Unfortunately, for attackers, the decline of straightforward stack
1
And perhaps, this year, on the desktop.

overflow vulnerabilities (and the adoption of effective mitigations,
such as stack canaries), leaves no other option than to accept this
complexity, brittleness, and additional primitive requirements.
In this paper, we bridge this exploitation gap by developing
a general technique to prepare ROP payloads on the stack. Our
technique exploits the intended design of the kernel stack: Linux’s
kernel stack is designed to save various forms of data, including
user-controlled data from user space. Attackers can leverage this
intended storage to store carefully-crafted malicious data in kernel
space, that they can access after triggering vulnerabilities through
stack-pivoting.
In studying the implications of these capabilities, we realized that
the Linux kernel stack design can be utilized as an attack surface
for malicious attackers. We built on our discovery to propose both
a novel exploitation technique and a new mitigation to defend
against it. Our technique, RetSpill, enables exploits that bypass most
existing kernel security mitigations (and emerging mitigations such
as Function Granular Kernel Address Space Layout Randomization
[34]) with no other requirements (such as register control or specific
memory configuration requirements that limit other techniques).
Importantly, RetSpill can be semi-automated, demonstrating that
the bar for successful Linux kernel attacks is significantly lower
than where it is currently assumed to be by the security community.
To comprehensively understand RetSpill’s potential impact, we
identify the scenarios where user-controlled data appears on the
kernel stack (§4.2), and we quantify the size of user-controlled
data to check if they are sufficient for a privilege escalation exploit.
We discover four different scenarios (one of them is discovered
by another researcher in parallel to this research [54]), three of
which are Linux kernel’s intended operations which are inevitable
by design. We also find that, Linux system calls typically leave
enough user-controlled data for attackers to launch a privilege
escalation exploit. Specifically, our measurement shows that, given
Linux kernel’s intended operations, the user-controlled data in
a Linux system call can hold 11 ROP gadgets on average. Even
worse, we found that given Linux kernel’s current design, 11 ROP
gadgets are sufficient for privilege escalation (§4.3). Through clever
downstream applications, one can take advantage of the 11 gadgets
to obtain unlimited Arbitrary Read/Write/Exec primitives in kernel
space and can even call and retrieve return values from kernel
functions.
We show the power of RetSpill by applying it to 22 real-world
vulnerabilities, demonstrating its ability to achieve successful ex-
ploitation on 21 of them, with fewer primitive requirements and
more reliability than existing public exploits for these vulnerabil-
ities. Critically, because the technique is so applicable, and very
few mitigations are effective against it to any extent, we were able
to implement RetSpill as a semi-automated pipeline that directly
synthesized 20 of these exploits. The only manual effort needed is
providing the CFHP and integrating the output of the pipeline into
the exploit.
Finally, we investigate RetSpill from a defensive perspective,
checking it against all existing commonly-adopted protections
(which cannot defend against it) and proposing new protection
to mitigate the impact of this dangerous exploitation technique and
re-raise the bar of Linux kernel exploitation.
In summary, this paper makes the following contributions:
• We identify the kernel stack as an attack surface in Control
Flow Hijacking exploitation and study the methods to place
user-controlled data on the kernel stack.
• By accessing user-controlled data on the kernel stack, we
devise a novel and powerful exploitation technique, RetSpill,
that can bypass commonly-adopted protections in the Linux
kernel and enable powerful exploitation of Control Flow
Hijacking vulnerabilities.
• We evaluate RetSpill on 22 real-world vulnerabilities and
demonstrate its ability to break the security boundary be-
tween user space and kernel space.
• We propose a new protection to harden Linux kernel security.
Combined with existing protections, the new defense can
mitigate the impact of the powerful RetSpill exploitation
technique.
To foster future research, we released the artifacts, including
RetSpill and all the experiment data
2
. This will benefit the commu-
nity by letting researchers understand the severity of RetSpill and
inspiring new protections to harden the Linux kernel.
Ethics.
We have contacted the Linux kernel security team and
responsibly disclosed the exploitation technique. We are collaborat-
ing with the Linux community on the contribution of our defense.
The kernel security team has given us permission to publish this
research to the community.
2
BACKGROUND
In this section, we present the technical background of Linux kernel
security, including primitives, vulnerabilities, attacks, and modern
defenses.
Linux Kernel Exploits.
Typically, the goal of a Linux kernel
exploit is to use kernel vulnerabilities to escalate privilege from
a less privileged user (e.g., nobody) to root. Compared to user
space-level exploitation, where, for example, an attack is considered
successful once a shell is achieved, Linux kernel exploitation needs
to additionally consider safely returning to the user space without
triggering a kernel panic or killing the escalated user space process.
Exploitation Primitives and the Control Flow Hijacking Prim-
itive.
An exploitation primitive represents a machine state transi-
tion where a security policy is violated. With a control flow hijacking
primitive (CFHP), the attacker gains control of the kernel’s program
counter (PC). In this paper, we will use “CFHP” and the “PC-control”
terminology interchangeably. Note that we do not assume the ca-
pability of controlling registers other than the program counter, or
controlling the contents pointed to by any register.
Control Flow Hijacking Exploits.
A control flow hijacking
(CFH) exploit starts with CFHP. It amplifies CFHP to better primi-
tives, such as Return Oriented Programming (ROP) and shellcode
execution, and eventually obtains privilege escalation. Before mod-
ern defenses, obtaining CFHP in the Linux kernel directly led to
privilege escalation, but it is no longer this simple in the modern
era.
Existing Protections Against CFH Attacks.
With increas-
ingly powerful defenses developed by the Linux kernel, exploiting
2
https://github.com/sefcom/RetSpill

Technique
Required Primitives
Data Region
Reliable*
Payload
Still
Mitigation
Rewrite
Applicable
ret2usr [37]
CFHP
user space
✓
✓
✗
SMEP
ret2dir [31]
CFHP+physmap leak
physmap
✗
‡
✓
✗
NX-physmap
pivot to user [18]
CFHP+codebase leak
user space
✓
✓
✗
SMAP
change CR4 [49]
CFHP+codebase leak+rdi control
user space
✗