Exploiting the Linux Kernel for

Privilege Escalation
Pietro Borrello
Who am I

Ph.D. Student at Sapienza University of Rome

Working on:
• Microarchitectural Attacks
• Side Channels
• Program Analysis
• Fuzzing

TRX
Our Journey
1. Setting up the environment

2. First Steps in Kernel Memory

Corruption

3. Gaining Root Privileges

4. Linux Kernel Mitigations

5. Bypassing Linux Kernel

Mitigations
 Setting Up the
Environment
1 2 3
Fetch & Build Run the Kernel Debug the
the Linux Kernel in qemu kernel
 Fetch & Build the Linux Kernel

1. Get in touch with Kernel source code on bootlin

 Fetch & Build the Linux Kernel

1. Get in touch with Kernel source code on bootlin

2. Use buildroot to configure and build the kernel
 Fetch & Build the Linux Kernel

1. Get in touch with Kernel source code on bootlin

2. Use buildroot to configure and build the kernel
3. Collect the output files
Debug the Kernel

see:

• https://github.com/hugsy/gef

• https://github.com/martinradev/gdb-pt-dump
 First Steps in
Kernel Memory
Corruption
1 2 3
Kernel Attack Common Bugs Arbitrary Code
Surface Execution: is it
necessary?
 Linux Kernel Attack Surface

OEM
Customizations Device
Loadable Drivers
Kernel
Modules

syscall
interface
Coprocessors
 Common bugs

• Read out of bounds

• Writes out of bounds
• Type confusions
• Use After Free
• Uninitialized memory
• Integer Overflows
 Common bugs

• Read out of bounds

• Writes out of bounds
• Type confusions
• Use After Free
• Uninitialized memory
• Integer Overflows
 Common More Interesting bugs

• Direct userspace pointer usage

• TOCTOUs / Double Fetches
• Race Conditions
• Improper Permissions
 Direct userspace pointer usage

The kernel has to deal with pointers from userspace that are untrusted
What if ptr or ptr->data points to kernel space?
 Direct userspace pointer usage

The kernel has to deal with pointers from userspace that are untrusted
What if ptr or ptr->data points to kernel space?
-> Add check to verify
 Double Fetches

Let’s assume you need to copy content from userspace

 Double Fetches
Let’s assume you need to copy content from userspace
Ok maybe this is secure…
 Double Fetches
Let’s assume you need to copy content from userspace
Arbitrary Code Execution: is it
necessary?

ring0
FREE

root

user
 Gaining Root
Privileges
1 2 3
The ACE way The AAW way The 1337 way
ACE: Arbitrary Code Execution

AAW: Arbitrary Address Write

AAR: Arbitrary Address Read

1337: 1337
 The ACE way - ret2usr

Let’s start easy:

• controlled function pointer
• no kernel mitigations in place

…but what should we do?

 The ACE way - ret2usr
The goal is to achieve root privileges in the system.
• The kernel holds privilege information in the task_struct
 The ACE way - ret2usr
The goal is to achieve root privileges in the system.
• The kernel holds credentials information in the task_struct
• uses functions to update them
 The ACE way - ret2usr
The goal is to achieve root privileges in the system.
• The kernel holds credentials information in the task_struct
• uses functions to update them
• and to generate new ones
 The ACE way - ret2usr

1. Leverage the same kernel functions to change credentials to root ones.

• how to find the location of these functions?
/proc/kallsyms: list of the addresses of all symbols loaded in the kernel
• without KASLR: get the address directly

• with KASLR: get the offset w.r.t. kernel .text base

 The ACE way - ret2usr

1. Leverage the same kernel functions to change credentials to root ones

 The ACE way - ret2usr

1. Leverage the same kernel functions to change credentials to root ones

Now we are root! But how to safely return to userspace to spawn a shell?
 The ACE way - ret2usr

1. Leverage the same kernel functions to change credentials to root ones

2. Return to userspace by restoring the right context
 The ACE way - ret2usr

1. Leverage the same kernel functions to change credentials to root ones

2. Return to userspace by restoring the right context
3. Enjoy root
 The AAW way

What if we don’t have kernel arbitrary code execution?

Let’s assume an Arbitrary Address Write primitive
 The AAW way

What if we don’t have kernel arbitrary code execution?

Let’s assume an Arbitrary Address Write primitive

… but what and where to write?

 The AAW way
We already know some interesting pointers to overwrite…
commit_creds just overwrites them
 The AAW way
We already know some interesting pointers to overwrite…
commit_creds just overwrites them
 The AAW way

Overwrite real_cred and cred in current_task with root credentials

 The AAW way

Overwrite real_cred and cred in current_task with root credentials

A few details:
• how to find current_task
• how to generate/find root credentials
 The AAW way

• how to find current_task

 The AAW way

• how to find current_task

• how to generate/find root credentials
there already exists init_cred as a global variable in the kernel data
 The AAW way

1. Overwrite current_task ->real_cred and current_task ->cred with init_cred

2. Enjoy root
 The 1337 way - modprobe_path

modprobe is used to add a loadable kernel module to the Linux kernel

• the kernel can automatically load

modules executing modprobe as root
when needed. e.g., using different
network protocols, unknown files
• the path to modprobe binary is stored
in the modprobe_path global var
• modprobe_path is in a RW kernel
page by default
 The 1337 way - modprobe_path

1. overwrite modprobe_path using a kernel AAW primitive with the path

of a binary that we control
2. trigger modprobe_path execution, .e.g., executing unknown binary format
3. Enjoy root
Linux Kernel
Mitigations
1 2 3
Prevent KASLR & Friends Kernel Hardening
code/data
hijacking
 Prevent hijacking - SMEP

We saw how controlling a code pointer may just allow us to jump back to
userspace, and execute arbitrary code at ring0
Supervisor Mode Execution Protection:
• prevent executing from userland pages when in kernel mode
• controlled by 20th bit of cr4

jmp

ring0 ring3
kernel userspace
 Prevent hijacking - SMEP

• controlled by 20th bit of cr4

Can we bypass it?
1. jump to native_write_cr4 and reset the bit
2. jump to userspace

jmp

ring0 ring3
kernel userspace
 Prevent hijacking - SMEP

• controlled by 20th bit of cr4

Can we bypass it?
1. jump to native_write_cr4 and reset the bit
the kernel explicitly prevents writes to sensitive cr4 bits

jmp

ring0 ring3
kernel userspace
 Prevent hijacking - SMEP

Can we disable it? NO

What if we ROP on kernel code?
1. find pivoting gadget in kernel code mov rsp, 0x1337000; ret;

2. pivot to ropchain from user data

prepare_kernel_cred(0);
commit_creds();
swapgs; ret;
iret;
 Prevent hijacking - SMAP

We saw how controlling a pointer may allow us to ROP from userspace, and
execute arbitrary code at ring0
Supervisor Mode Access Prevention:
• prevent accessing data from userland pages when in kernel mode
• controlled by 21st bit of cr4 (pinned bit)

access

ring0 ring3
kernel userspace
 Prevent hijacking - SMAP

Supervisor Mode Access Prevention:

• prevent accessing data from userland pages when in kernel mode
Wait… how do you pass data to the kernel then?
syscall: write(1, buffer, 0x100);

access

ring0 ring3
kernel userspace
 Prevent hijacking - SMAP

Supervisor Mode Access Prevention:

• prevent accessing data from userland pages when in kernel mode
• Fast way to disable SMAP through kernel EFLAGS.AC
 Prevent hijacking - KPTI

Kernel Page Table Isolation

prevent attacks on the shared user/kernel address space, with two sets of
pages:
1. userspace page tables with minimal amount of kernel pages
2. kernel page tables with user pages mapped as NX
Mitigation with an prepare_kernel_cred(0); prepare_kernel_cred(0);
effect similar to
SMEP for exploitation commit_creds(); commit_creds();
swapgs; ret; KPTI trampoline
iret;
 KASLR

Kernel Address Space Layout Randomization

Randomize different sections of the kernel independently:
• text segment
• modules
• direct physical map
• …
Lower entropy than userspace ASLR, but here a crash means system crash
-> need to leak KASLR addresses using an AAR primitive/side-channels
 FG-KASLR

Function Granular Kernel Address Space Layout Randomization

Random shuffle of kernel code on a per-function granularity at every boot
-> a single leak is no more sufficient to derandomize the entire kernel
address space

prepare_kernel_cred commit_creds do_mmap

commit_creds do_mmap prepare_kernel_cred
copy_from_user prepare_kernel_cred copy_from_user
do_mmap copy_from_user commit_creds
 FG-KASLR

However…
Certain regions of the kernel cannot be randomized.
• initial _text region
• KPTI trampoline
• kernel symbol table ksymtab
 FG-KASLR
Wait what? ksymtab
It is needed to export symbols so that they could be used by kernel modules
 FG-KASLR
Wait what? ksymtab
It is needed to export symbols so that they could be used by kernel modules
 FG-KASLR
Wait what? ksymtab
It is needed to export symbols so that they could be used by kernel modules

Bypass:
1. Leak _text image base address using an AAR
2. Compute the address of _ ksymtab_<func> from _ text base
3. Leak the value_offset entry from _ ksymtab_<func>
 Structure Layout Randomization

Usually fields in a C structure are laid out by the compiler in order of their
declaration.

field1
field2
field3
field4
 Structure Layout Randomization

Usually fields in a C structure are laid out by the compiler in order of their
declaration.
Randomly rearrange fields at compilation time, using a random seed.

field4
field1
field3
field2
 Structure Layout Randomization
task_struct may have their layout randomized. How can we overwrite creds?
 Structure Layout Randomization
task_struct may have their layout randomized. How can we overwrite creds?
-> need to reverse engineer the vmlinux binary to recover the field offsets
 Kernel Hardening

Build the kernel with different security options to harden its attack surface
• Attack surface reduction
• Enable security features
 Kernel Hardening

Build the kernel with different security options to harden its attack surface
• Attack surface reduction
• INIT_STACK_ALL: initialize all stack variables
• SECURITY_DMESG_RESTRICT: avoid leaks of kernel pointers in dmesg
• PANIC_ON_OOPS: panic on kernel oops
• MODULE_SIG_FORCE: force modules to be signed
• BPF_JIT=n: disable BPF jitter
 Kernel Hardening

Build the kernel with different security options to harden its attack surface
• Enable security features
• STACKPROTECTOR_STRONG: improve stack canary coverage
• DEBUG_CREDENTIALS: keep track of pointers to cred struct
• HARDENED_USERCOPY: validate memory regions of user pointers
• SLAB_FREELIST_RANDOM/HARDENED: randomize/fortify allocators
• RANDOMIZE_KSTACK_OFFSET: randomize stack offset at each syscall
Kernel Hardening - USERMODEHELPER

The modprobe_path technique is so powerful that it has his own mitigation

CONFIG_STATIC_USERMODEHELPER:
Force all usermode helper calls through a single binary
 Kernel Hardening - SELINUX

SELinux defines access controls for every resource in a system.

• mandatory access control decisions made based on security policies
• every process and system resource has a SELinux context
• whitelist of the possible interactions between the SELinux contexts
Bypassing
Linux Kernel
Mitigations
1 2
kROP on Leveraging
physmap Useful Structures
 kROP - SMAP

SMAP prevents accessing data from userland pages when in kernel mode
Is Kernel ropping dead then?

access

ring0 ring3
kernel userspace
 kROP - SMAP

SMAP prevents accessing data from userland pages when in kernel mode
Is Kernel ropping dead then?
• directly place the chain in kernel land if you have control over some data
• indirectly place the chain in kernel land

access

ring0 ring3
kernel userspace
 kROP - SMAP

SMAP prevents accessing data from userland pages when in kernel mode
Is Kernel ropping dead then?
• directly place the chain in kernel land if you have control over some data
• indirectly place the chain in kernel land
T LY?
IR EC
IND
access

ring0 ring3
kernel userspace
 kROP - physmap

The kernel has a view of the whole physical memory mapped in physmap
-> This means userspace pages are aliased in kernel memory!
 kROP - physmap

The kernel has a view of the whole physical memory mapped in physmap
-> This means userspace pages are aliased in kernel memory!

access

ring0 ring3
kernel userspace

userspace
alias
 kROP - physmap

The kernel has a view of the whole physical memory mapped in physmap
-> This means userspace pages are aliased in kernel memory!
• originally the mapping was RWX! access
(now fixed)
ring0 ring3
• SMAP bypass: kernel userspace
1. spray ropchain pages in userspace
2. locate the page in physmap using AAR
3. ROP to physmap userspace
alias
 Leveraging useful structures

During kernel exploitation you have a lot of control on the objects that are
allocated as consequence of actions performed in userspace.
Often you have bugs that give you limited capabilities during exploitation
and want to:
• promote an out-of-bound read/write to AAR/W
• promote AAR/W to RIP control
• RIP control to ACE

Let’s look at some useful structures the kernel uses and that we can leverage
 Useful structures - tty_struct

Created in kernel heap for each open(“/dev/ptmx”) syscall

-> useful for leaks and RIP control

Leak kernel heap address

Leak kernel base + RIP control

 Useful structures - msg_msg

Created in kernel heap for each msgsnd() syscall

-> Variable in size + up to 4048 bytes of arbitrary data

Leak kernel heap address

Copy of user data
 Useful functions - userfaultfd

userfaultfd lets you handle page faults on userspace, by defining a handler

that will be called to manage virtual memory.

But why is it useful?

-> we can make the kernel hang on user data access, while waiting for the
handler execution
-> deterministically enlarge race condition windows
 Useful functions - setxattr

For each setxattr syscall the kernel allocates a buffer in heap with data
completely controlled by userspace. Couple with userfaultfd to avoid dealloc

Copy of user data in

kernel heap
 Takeaway

With strong enough exploitation primitives, any mitigation can be bypassed.

Are we doomed?
• coverage guided kernel fuzzing to find bugs:
https://github.com/google/syzkaller
• secure programming to avoid bugs:
https://github.com/Rust-for-Linux
Thanks
Do you have any questions?
[email protected]
@borrello_pietro

CREDITS: This presentation template was created by

Slidesgo, including icons by Flaticon, infographics &
images by Freepik
 Resources (1)

● GET IN THE MOOD: https://www.youtube.com/watch?v=G1IbRujko-A

● https://github.com/smallkirby/kernelpwn

● https://github.com/pr0cf5/kernel-exploit-practice

● https://lkmidas.github.io/posts/20210123-linux-kernel-pwn-part-1/

● https://lkmidas.github.io/posts/20210223-linux-kernel-pwn-modprobe/

● https://devilinside.me/blogs/small-steps-kernel-exploitation

● https://duasynt.com/blog/linux-kernel-heap-spray
 Resources (2)

● https://ptr-yudai.hatenablog.com/entry/2020/03/16/165628

● https://googleprojectzero.blogspot.com/2020/02/mitigations-are-attack-surface-too.html

● https://blog.lexfo.fr/cve-2017-11176-linux-kernel-exploitation-part1.html

● https://meowmeowxw.gitlab.io/ctf/3k-2021-klibrary/

● https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html

● https://akulpillai.com/posts/learning_through_challenges1/

● https://github.com/R3x/How2Kernel
 Resources (3)

● https://pr0cf5.github.io/ctf/2020/03/09/the-plight-of-tty-in-the-linux-kernel.html

● https://www.graplsecurity.com/post/kernel-pwning-with-ebpf-a-love-story