From Collision To Exploitation: Unleashing Use-After-Free Vulnerabilities in Linux Kernel

Transcription

1 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 Shanghai Jiao Tong University CCS

2 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

3 Use-after-free in Linux kernel 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 CCS

4 Exploiting use-after-free bugs Our goal to is re-occupy the vulnerable freed object 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

5 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 objects. CCS

6 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

7 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

8 Overview CCS

9 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

10 Object-based Attack CCS

11 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

12 Object-based Attack #1 Collisions between Objects of the Same Size Notice that the length of the message buffer should be the same as the size of the vulnerable object (512). Limitation: kmalloc() allocates space of a rounded size like 32, 48, 64, 128, 256, 512, 1024 What if the vulnerable object has a size of 576? 512 < 576 < 1024 CCS

13 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

14 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

15 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 useafter-free vulnerabilities in Linux kernel. CCS

16 Physmap-based Attack 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. CCS

17 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 occupying free kernel space. Table [1] from ret2dir: Rethinking Kernel Isolation (USENIX 14 ) CCS

18 Physmap-based Attack 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? CCS

19 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

20 Physmap-based Attack In practical, we discover that users can get certain data inside many kernel objects 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 CCS

21 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

22 Evaluation 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. CCS

23 Evaluation We achieve a reliable universal root solution on diverse Android devices by leverage CVE , 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. CCS

24 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

25 Thank you! Q&A Shanghai Jiao Tong University CCS