Hands Off and Putting SLAB/SLUB Feng Shui in a Blackbox

The presentation discusses a solution to exploit vulnerabilities in the kernel through static analysis and building a database of useful objects and system calls.

• Building a database of Conor objects and system calls to allocate, deallocate, and dereference them
• Using static analysis to identify useful objects and system calls from the source code
• Focusing on victim and spray objects for exploitation
• Customizing a call graph to identify potential system calls
• Bypassing certain mitigations through control flow hijacking

The speaker explains that the solution focuses on exploiting vulnerabilities in the kernel and not discovering them. They clarify that the solution is not meant to be executed from user space programs, but rather from within the kernel. They also address the limitations of the solution, such as the need for credentials to load dynamically loadable kernel objects and the difficulty of bypassing certain mitigations like PA see.

Successful exploitation against a Linux kernel vulnerability requires the manipulation of memory layout. Over the past years, security researchers have already invented and summarized various memory layout manipulation mechanisms. However, it is still challenging for an attacker to use these manipulation mechanisms to perform exploitation in the real world. This is mainly because an adversary lacks the following knowledge -- (1) which system calls to use to allocate an object of interest and (2) how to systematically adjust system calls to obtain the desired memory layout. In order to perform exploitation, an adversary needs to select memory layout manipulation approaches and then place the corresponding object. Take an out-of-bounds (OOB) vulnerability for example. In order to hijack the control flow, one should overwrite the critical data in the adjacent object. However, it is common that the adjacent object may not contain critical data such as function or object pointers. Therefore, the most common operation for an adversary is to allocate an appropriate object to the corresponding location prior to the trigger of that vulnerability. For this particular example, it should be an object with a pointer placed at the position adjacent to the vulnerable object. In addition, the adversary has to ensure the OOB vulnerability gives him the freedom to overwrite the data at the address corresponding to the target pointer. In the Linux kernel, SLUB/SLAB allocator manages and groups data objects based on their types and sizes. Only the data objects sharing the same type and similar sizes could be placed in the same slab. As a result, when selecting appropriate objects for memory layout manipulation, an adversary has to take the vulnerable object into consideration and select only those objects that could be placed on the same slab. According to our measurement, the Linux kernel has thousands of distinct data objects with various sizes and types. In order to allocate them to the slab, an adversary has to utilize corresponding system calls. Unfortunately, given a target object that could be potentially helpful for obtaining control over the program counter, it is generally difficult for the adversary to identify the corresponding system call to allocate that target object. Presumably as such, many vulnerabilities have not yet demonstrated their exploitability publicly. And, the lack of knowledge about system calls also leads adversaries to repeatedly employ the same data objects to perform exploitation. According to recent studies, this repeated data object usage facilitates security analysts to build intrusion signatures and thus ease their identification for the potential intrusion. In fact, even if an adversary tracks down the system calls for a particular object, it is still difficult for him to obtain the desired memory layout. This is because, when allocating the target object, in addition to the object of interest, the system calls identified also allocate or deallocate other kernel objects, resulting in unexpected variation in memory layout. Take the aforementioned OOB case for example again. The OOB vulnerability provides an adversary with the ability to overwrite critical data in its neighbor object. Using a set of system calls, an adversary could allocate a victim object containing a function or object pointer on the target slab. However, along with the allocation of the victim object, the system calls at the first place might allocate irrelevant kernel objects, which makes the victim object turn out to be at an unexpected spot. When this situation occurs, adversaries typically look for alternative system calls or adjust memory layout in an ad-hoc manner. In practice, it is not guaranteed to find a memory layout through these two approaches. As a result, the side effect involved by system calls further reduces the number of system calls available and even jeopardizes the exploitability of that vulnerability. In this talk, we will introduce a precise automated memory layout manipulation technique. We will demonstrate that using this manipulation technique, an attacker could not only easily identify the system calls tied to the objects of interest but, more importantly, automatically assemble system calls to adjust memory layout and thus obtain the desired memory layout useful for exploitation. Different from existing automated memory layout manipulation techniques, our technique does not use a large corpus of testing cases to search the memory layout desired. Rather, it first leverages a static analysis technique to identify all the system calls potentially helpful for object allocation and free. Then, it utilizes the system calls as prior knowledge to allocate and deallocate objects on the slab and thus obtain the memory layout useful for exploitation. In the process of memory layout manipulation, our technique is guided by an algorithm. Along with this talk, we will specify how we design this algorithm and showcase how it automates memory layout manipulation. Along with this talk, we will also release various working exploits against 30+ latest kernel vulnerabilities. These exploits are designed through our memory layout manipulation technique. For the ease of reviewers to assess of our talk, we have uploaded some exploits at https://www.dropbox.com/sh/2kwcwqb8rjro80j/AAC8QBCIhcCylNUDLUd1OZCZa?dl=0