KOOBE: Towards Facilitating Exploit Generation of Kernel Out-Of-Bounds Write Vulnerabilities
Total Page：16
File Type：pdf, Size：1020Kb
KOOBE: Towards Facilitating Exploit Generation of Kernel Out-Of-Bounds Write Vulnerabilities Weiteng Chen Xiaochen Zou Guoren Li Zhiyun Qian UC Riverside UC Riverside UC Riverside UC Riverside Abstract from Microsoft [37], around 70% of security bugs that were The monolithic nature of modern OS kernels leads to a con- fixed between 2006 and 2018 are memory safety bugs. These stant stream of bugs being discovered. It is often unclear bugs can lead to serious consequences such as privilege esca- which of these bugs are worth fixing, as only a subset of them lation, allowing an attacker to gain complete control over a may be serious enough to lead to security takeovers (i.e., privi- system [6, 57, 59]. lege escalations). Therefore, researchers have recently started What’s worse, because these alleged security bugs are re- to develop automated exploit generation techniques (for UAF ported every day, it is challenging for developers to keep bugs) to assist the bug triage process. In this paper, we inves- up. According to the Google’s syzbot dashboard [25], which tigate another top memory vulnerability in Linux kernel — reports bugs from continuously fuzzing Linux kernels, in a out-of-bounds (OOB) memory write from heap. We design single year (from Aug 2017 to Sep 2018), there were 1,216 KOOBE to assist the analysis of such vulnerabilities based Linux kernel bugs discovered by syzkaller [26] and fixed. on two observations: (1) Surprisingly often, different OOB This translates to an average of 3.42 Linux kernel bugs dis- vulnerability instances exhibit a wide range of capabilities. covered daily by syzbot alone. It is no surprise that it has taken (2) Kernel exploits are multi-interaction in nature (i.e., mul- developers weeks and even months to fix security bugs [34]. tiple syscalls are involved in an exploit) which allows the Given such a long procedure, the key missing piece is the exploit crafting process to be modular. Specifically, we fo- ability to separate wheat from chaff — prioritizing the fix of cus on the extraction of capabilities of an OOB vulnerability security bugs that are positively exploitable. To this end, a which will feed the subsequent exploitability evaluation pro- promising direction is to automate the exploit generation of cess. Our system builds on several building blocks, including common types of memory corruption vulnerabilities [12, 17, a novel capability-guided fuzzing solution to uncover hidden 27, 54, 56] and prioritize those that are eminently exploitable. capabilities, and a way to compose capabilities together to These studies employ various program analysis techniques to further enhance the likelihood of successful exploitations. In search for a possible exploit path (that can achieve arbitrary our evaluation, we demonstrate the applicability of KOOBE code execution) given a Proof-of-Concept (PoC) test case. by exhaustively analyzing 17 most recent Linux kernel OOB Exploits of OS kernel vulnerabilities have unique charac- vulnerabilities (where only 5 of them have publicly available teristics compared to those of user applications — any kernel exploits), for which KOOBE successfully generated candi- exploit is multi-interaction by design, involving a sequence date exploit strategies for 11 of them (including 5 that do of attacker-chosen inputs (i.e., syscalls and their arguments) not even have any CVEs assigned). Subsequently from these where one is dependent on another; this is in contrast with strategies, we are able to construct fully working exploits for many user applications such as command line programs that all of them. take input in one-shot. Coupled with the fact that OS kernels maintain massive internal states, they lead to a huge search space to locate exploitable states. In practice, many more 1 Introduction syscalls are typically added to a PoC to form an exploit that can fully hijack the control flow or escalate privileges. Operating system (OS) kernels play a critical role in securing On the other hand, multi-interaction exploits also create the computing infrastructure that we rely on on a daily basis. opportunities for “divide-and-conquer” where we break down Unfortunately, OS kernels such as Linux are mostly written in an exploit into a series of goals which can be reasoned about the C language which is inherently type unsafe and frequently and achieved separately. Up to this point, only the use-after- leads to memory safety errors. According to a recent report free (UAF) bugs have been explored in the context of kernel exploit generation [56, 57]. and we believe it represents an important step towards the In this paper, we investigate another top memory vulnera- ultimate goal. Specifically, given a PoC triggering one or bility in Linux kernel — out-of-bounds (OOB) memory write more OOB accesses, our system generates exploit primitives from heap (25 UAF write vs. 28 heap OOB write bugs from to achieve Instruction Pointer (IP) hijacking. Aug 2017 to Sep 2018 on syzbot [25]). As the name suggests, We assume that the kernel is protected by widely-deployed OOB vulnerabilities cause the kernel to access locations out- defenses including Address Space Layout Randomization side of the expected memory region (e.g., writing outside of (KASLR), Supervisor Mode Execution Prevention (SMEP), a heap buffer). Exploiting Linux kernel OOB memory write and Supervisor Mode Access Prevention (SMAP). How- vulnerabilities (OOB vulnerabilities in short) presents unique ever, bypassing them is usually performed after a successful challenges. Surprisingly often, different OOB vulnerability IP hijacking and thus considered independent of this work instances exhibit a wide range of capabilities, which we con- (see §4.5). Nevertheless, complementary techniques exist that sider roughly as how much maneuver space a vulnerability can address these limitations [32,55,57]. Among these, KE- gives to the attacker. In the case of OOB, the capabilities are PLER [55] is especially noteworthy as it can automatically defined in terms of how far the write can reach, how many turn IP controls into arbitrary code execution unconditionally. bytes can be written, and what value can be written (see a more formal and complete definition in §4.2). For example, 3 Background and Motivating Example CVE-2016-6187 can overwrite only one single byte; CVE- 2017-7184 can write more bytes but only the same fixed value. The basic idea in crafting a kernel OOB write exploit is Coupled with the diversity of kernel memory objects and their straightforward — when an OOB write access occurs, an ad- fitness of exploitation (e.g., whether a function pointer ex- versary would pre-arrange the memory layout such that some ists at a desired offset), it effectively becomes a necessity to critical data is overwritten (e.g., a function pointer), which understand and summarize the precise capability of individ- can be used to perform control flow hijacking. However, in ual kernel OOB vulnerabilities. Even worse, we find that a practice it is often labor-intensive and sometimes infeasible PoC (e.g., generated by syzkaller [26]) sometimes fails to for a security analyst to manually craft an exploit. As we will exercise the complete capability of a vulnerability, making it elaborate through a real-world kernel OOB vulnerability, this seemingly unexploitable. is because that (1) a PoC program may not fully explore the To this end, we develop KOOBE that automates the pro- capability of an OOB vulnerability; (2) there is often a huge cess of all key steps in evaluating a kernel OOB vulnerability, search space to locate an appropriate memory layout that can focusing on the key module of capability extraction, which facilitate the exploit. We go through a concrete example to feeds into subsequent exploitability evaluation. We demon- illustrate this process. strate the applicability of KOOBE by analyzing 17 OOB Fig. 1a shows a simplified excerpt of the vulnerable code in vulnerabilities (7 CVEs), for which KOOBE successfully Linux Kernel 4.14.0 (CVE-2018-5703). Following the same generated candidate exploit strategies for 11 of them. terminology in [54], we denote the site where the security We make the following contributions: violation happens, e.g., Kernel Address Sanitizer (KASAN) reports an OOB access at line 12, as a vulnerability point. • We distill key challenges in exploiting Linux kernel OOB Also, a typical heap OOB exploit involves two kinds of ob- vulnerabilities and design an effective analysis frame- jects: we denote the object intended to be accessed as the work focusing on capability extraction that captures the vulnerable object (vul in line 12) and the overwritten one intrinsics of this specific type of vulnerabilities. containing critical data (e.g., a function pointer) as the target • We implement KOOBE primarily on top of Syzkaller, object. As we can see in this example, the size of the vul- S2E and Angr with 10,887 LoC. We release the source nerable object is fixed, but there is a type confusion bug at code of KOOBE to facilitate further research (https: line 11 leading to an OOB write at line 12 (where 8 addi- //github:com/seclab-ucr/KOOBE). tional bytes will be overwritten). At first glance, we might conclude that this vulnerability allows a write of a constant • We thoroughly evaluate KOOBE using known CVEs 0x08080000000000, which is not so interesting as it is neither as well as crash reports from syzbot. We show that it is a valid kernel space pointer nor user space pointer. However, extremely effective to aid the exploit crafting process. the overflown content is in fact controllable by an adversary if sys_setsockopt is invoked before triggering the OOB 2 Scope and Assumptions access (its argument controls the value of gsock.option). Unfortunately, this invocation is missing in the original PoC, Automatic Exploit Generation (AEG) against monolithic ker- limiting the value/exploitability of the bug.