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 GoSSIP@LoCCS CCS 2015 1 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 • 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 2015 3
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 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 objects. 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 • 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 2015 12
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 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 2015 16
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 2015 17
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 2015 18
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 • 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 2015 20
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 • 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 2015 22
Evaluation 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. CCS 2015 23
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 GoSSIP@LoCCS CCS 2015 25 Shanghai Jiao Tong University
Recommend
More recommend
