Introduction
This paper was published in CCS 2015. With the introduction of the various mitigation deployed in the user space, especially sandbox, the vulnerability in the linux kernel has become a target of the attacker. However, the memory space in the kernel is hard to predict since the kernel space are used by various tasks. In this paper, the author introduces a much stabler way to put desired vulnerable target into kernel memory space by exploiting a use-after-free in linux kernel.
Background
As the usual exploit on UAF vulnerability, attacker’s goal is to put the crafted object to a location where an object has been de-allocated previously. If the attacker can fill the crafted object with controlled data, it is possible for attacker to hijack control flow for further exploitation.
The code above is the sample vulnerable code introduced in the paper, and will be used for demonstrating PoC exploits. In this paper, it introduces two methods to achieve memory collision: Object-based attack and Physmap-based attack. For more knowledge about SLUB allocator, please refer to my Linux Kernel Allocator. I will just mention a few words about them here.
Object-Based Attack
In linux kernel, the SLAB/SLUB allocators are responsible for allocations of kernel objects. For kernel objects of a specific type, a corresponding storage unit is created by the allocator as a container, which is called SLAB cache.
(The whole sentence is quoted from the original paper. I prefer to call that “slab cache” not “SLAB cache”, because SLAB in context of my blog refers to SLAB allocator. I will quote the original word in the paper. But I think it is still necessary to mention about it to avoid possible confusion.)
The SLAB/SLUB allocators introduce mainly two restrictions to an attack. First, SLAB caches separate kernel objects of one type from those of another type (object_type cache or kmalloc-size cache), which introduces implicit heap separation. Second, when an object is to be allocated, there might exist several half-full SLAB caches which are available to store it. The process to fill those holes in the SLAB cache is called defragmentation.
The basic exploitation process is given below:
Collisions between Objects of the Same Size
Since the kernel objects of different types are classified into the same cache if they have an identical size. This behavior allows attackers to create memory collisions between kernel objects of the same size. And an sample exploit is shown below:
Here we can find that the exploit used sendmmsg to create objects with controlled data and controlled size. A recent blog [1] from Vitaly Nikolenko explains that more clearly.
Collisions between Objects of Different Sizes
For the SLAB allocator in Linux kernel, if all objects in one SLAB cache are freed, the entire SLAB cache is going to be recycled for a future allocation. Thus for the new attack, several new SLAB caches are created and filled with vulnerable objects in the very beginning. And when all the objects in these SLAB caches are freed, the space of these SLAB caches previously created for vulnerable objects is going to be recycled by the kernel.
Physmap-Based Attack
The physmap attack is originally used in ret2dir technique. Physmap attack allows data crafted by the attacker in user space is directly mapped into kernel space and rewrite the kernel memory previously occupied by freed vulnerable object by exploiting use-after-free vulnerabilities.
Once attackers call mmap with an expected virtual address in user space and then call mlock on that virtual address, these pages in user space may be directly mapped into the physmap in kernel space.
To improve the probability that memory collisions happen between target objects and the physmap, the location where kernel objects are allocated should be lift up. The layout of the kernel memory including the SLAB caches and the physmap is shown in Figure 3. It can be seen that the physmap begins at a relatively low virtual address, meanwhile SLAB caches usually gather at a higher address. Our goal is to create memory collisions between these two areas.
Here there are many useful tricks mentioned in the paper. I just skip those to final final exploit.
Conclusion
This post only gives a brief introduction on the two proposed exploitation techniques mentioned in this paper. Beside the exploitation techniques, the paper also evaluates the feasibility of those exploitation techniques and proposes some potential mitigation techniques.
氷 菓 