Unleashing Use-After-Free Vulnerabilities in Linux Kernel Wen Xu , - - PowerPoint PPT Presentation

From Collision To Exploitation:

Unleashing Use-After-Free Vulnerabilities in Linux Kernel

Wen Xu, Juanru Li, Junliang Shu, Wenbo Yang, Tianyi Xie, Yuanyuan Zhang, Dawu Gu Group of Software Security In Progress Lab of Cryptology and Computer Security Shanghai Jiao Tong University

CCS 2015 1

GoSSIP@LoCCS Shanghai Jiao Tong University

Introduction

• Linux kernel becomes a welcomed target

– A complete control of the system – Less protection and mitigation schemes

• Exploiting kernel bugs is non-trivial

– Few documented techniques – Unpredictable memory layout

• Our goal is to find a generic way to exploiting

use-after-free bugs in Linux kernel.

CCS 2015 2

Use-after-free in Linux kernel

CCS 2015 3

• Option 2 is to free an object

without cleaning the pointer – obj[index] is so-called “a dangling pointer” since it points to a freed space

• Option 3 is to use an object

without checking whether the pointer is valid – Here “use” represents invoking a function pointer being stored in the object

Exploiting use-after-free bugs

• Our goal to is re-occupy the vulnerable freed
• bject with controllable data.

– The free memory is to be reused, which provides an opportunity for attackers to re-control the freed space. – Controllable data contributes to unintended control-flow hijacking or data corruption in later using.

CCS 2015 4

Challenges

• Stability: The “hole” should be re-occupied by our

candidates.

– Hundreds of scheduled tasks all affect kernel allocators.

• Separation: The “hole” should be re-occupied by proper

candidates.

– Different types of kernel objects cannot be stored in the same memory region due to SLAB/SLUB.

• Data-control: The “hole” should be filled with meaningful

content.

– The content of kernel objects are usually not fully controlled by users.

• Universality: One strategy regardless of types of vulnerable
• bjects.

CCS 2015 5

Insight: Memory Collision

• Kernel recycles free memory for future use.

– Memory limitation – Performance requirement – Reduction of the entropy of memory layout

• Memory collision attack strategy

– To use proper candidates and let them be chosen by the kernel to occupy the recently freed space

• In fact, to collide with the freed “hole”

– Probabilistic model with high success rate

CCS 2015 6

Overview

• Object-based memory collision attack

– Candidate: kernel buffers allocated by kernel allocators

• Physmap-based memory collision attack

– Candidate: physmap – Generic, stable and reliable

CCS 2015 7

Overview

CCS 2015 8

Object-based Attack

• Intuitive strategy

– To use kernel objects overwriting kernel objects

• Kernel objects are stored in various kinds of

SLAB caches.

– Different caches are for different objects which implies a natural separation. – How to insert an object of type A into the caches storing vulnerable objects of type B?

CCS 2015 9

Object-based Attack

CCS 2015 10

Object-based Attack #1 Collisions between Objects of the Same Size

• Savior: Newly adopted SLUB allocators

– Put objects of the same size into one cache for performance promotion.

• Candidate: kmalloc() buffers

– Used by kernel to store temporary data commonly – Easy to create by users: sendmmsg()

• Controllable size: Length of control message
• Controllable content: Data of control message
• All passed from userspace

CCS 2015 11

Object-based Attack #1 Collisions between Objects of the Same Size

CCS 2015 12

• Notice that the length of the

message buffer should be the same as the size of the vulnerable object (512).

• Limitation:

– kmalloc() allocates space

• f a rounded size like 32,

48, 64, 128, 256, 512, 1024… – What if the vulnerable

• bject has a size of 576?
• 512 < 576 < 1024

Object-based Attack #2 Collisions between Objects of Different Sizes

• If all the objects in a cache are freed, the

whole space of the cache is going to be recycled by the kernel.

– Is the space definitely to be re-used for a cache storing the objects of the original type? No. – Kernel never cares about the history of free

• memory. Memory is just memory.

– Chances are that the space is going to be used for a new cache storing objects of a different type.

CCS 2015 13

Object-based Attack #2 Collisions between Objects of Different Sizes

• The attack code remains to be the same.

– No care about the size of our message buffer – Pick a kmalloc() size you prefer

• Discussions

– Theoretically, collisions always happen eventually. – Practically, such a kind of blind strategy suffers a low success rate. – Usually due to the resource limitation, one user cannot own too many kmalloc() buffers in the kernel.

CCS 2015 14

Physmap-based Attack

• Get rid of restrictions provided by the kernel

allocators.

– Again, memory is just memory. The kernel never claims that the memory once for kernel objects is always for kernel objects. – We choose a candidate known as physmap to achieve a generic and stable attack against use- after-free vulnerabilities in Linux kernel.

CCS 2015 15

Physmap-based Attack

CCS 2015 16

Physmap, the direct-mapped memory, is memory in the kernel space which would directly map the memory in the user space into the kernel space.

Physmap-based Attack

• An EXCELLENT choice

– Easy creation: iteratively mmap() in the user space – Data-control: fully controlled by attackers for sure – Large size:

• Physmap filled with our crafted payload grows in the kernel by
• ccupying free kernel space.

CCS 2015 17 Table [1] from ret2dir: Rethinking Kernel Isolation (USENIX 14’)

Physmap-based Attack

CCS 2015 18

• An intuitive strategy is to

create a large amount of vulnerable objects and free all of them, then do the kernel spraying by physmap and hope the collision happens.

• A more reliable approach?

Physmap-based Attack

• We spray vulnerable objects in groups, for each group:

– Considering N objects as vulnerable ones, we will later trigger the UAF vulnerability on them. – Considering M(M >> N) objects as padding ones, we will just release them in a normal way.

• Result:
• (1) Large pieces of freed memory is waiting for

physmap with payload to occupy.

• (2) We have vulnerable freed objects scatter all over

the kernel space.

• These sharply increase the reliability of such a

probabilistic attack.

CCS 2015 19

Physmap-based Attack

CCS 2015 20

• In practical, we discover

that users can get certain data inside many kernel

• bjects by specific

syscalls.

• That could help to inform

attackers that the collisions have already happened and the spraying should be stopped.

– Further increase the reliability

Security Effectiveness

• Physmap-based attack totally avoids the separation

provided by the kernel allocators and achieves overwriting.

• Physmap originates from mmap() area in user space, thus it

is fully under the control of attackers.

• Physmap is effective regardless of what type and size of the

vulnerable object which has a use-after-free vulnerability.

• Certain spraying tricks and potential approaches to leaking

information helps to increase the probability that memory collisions happen.

• Physmap-based attack leverages the inherent working

mechanism of the kernel, which cannot be mitigated easily.

CCS 2015 21

Evaluation

CCS 2015 22

• Here is the performance of all these attacks targeting on the

custom vulnerable kernel module.

• In fact, the attack performs worse on 64bit Linux platform.

And also both physmap-based attack and object-based attack #1 have a high success rate.

Evaluation

CCS 2015 23

• We achieve a reliable universal root solution on diverse Android devices

by leverage CVE-2015-3636, a typical use-after-free vulnerabilities in Linux kernel credited to the author based on physmap-based attack.

• That implies our attack is applied both on x86/x86_64 and ARM

architectures.

Conclusion

• We propose a noval attack techniques to

unleash use-after-free vulnerabilities in Linux kernel which features reliability and universality.

• Countermeasures

– To impose restrictions on available memory resources of a particular user. – To make isolations among memory of different usages.

CCS 2015 24

Thank you! Q&A

CCS 2015 25

GoSSIP@LoCCS Shanghai Jiao Tong University