RetSpill: Igniting User-Controlled Data to Burn Away Linux Kernel Protections
§7.1), some cleverness is required to achieve full exploitation
tải về 0.65 Mb. Chế độ xem pdf
|
§7.1), some cleverness is required to achieve full exploitation. Independent ROP. Recall that the CFHP that initiates the ROP attack is provided by an overwritten victim object representing a system resource in kernel heap. Thus, all threads in the exploit process have access to the system resource, and also the victim object. An attacker can create a separate thread to execute the ROP chain so that ROP chain termination does not affect the main thread. This approach makes each ROP chain execution isolated in each thread, which means each ROP chain execution is performed under a different task context. Notice that this step does not involve re-triggering vulnerabilities for additional ROP chain iterations. Hence, in practice, it does not introduce extra unreliability for exploits (for example, from having to otherwise repeat heap massaging efforts). There are two advantages to this independent ROP chain execu- tion. First, as described in §2, it enables the use of the do_task_dead function as an epilogue gadget in the ROP chain to end the chain gracefully. Second, since the ROP payload is executed in a new thread, even if the ROP payload fails, the kernel will only terminate the executing thread instead of the main thread. Therefore, as we will describe in §7.3, one could repetitively try the execution of ROP payloads to bypass certain probabilistic kernel protections without exploit reliability degradation. Unlimited Arbitrary Read/Write/Exec. The victim object that gives the attacker CFHP is typically on the kernel heap and the attacker can put data on the kernel stack. Each time the attacker invokes the triggering system call, which grants the attacker CFHP, they can put different controlled data on the kernel stack and then invoke a different ROP chain. Combined with the Independent ROP Chain primitive, this feature of RetSpill effectively gives the attacker the ability to trigger different ROP chains as many times as desired without swapping payload in the kernel heap. Then the attacker can have unlimited Arbitrary Read/Write primitive, as well as the ability to invoke arbitrary functions in kernel space and get back the return values unlimited times. In other words, RetSpill turns one single CFHP into unlimited Arbitrary Read/Write/Exec without sacrificing exploit reliability. Putting it all together. At this point, the controlled victim object in the kernel heap becomes something analogous to a backdoor. By using the triggering system call on the victim object, the attacker can do Arbitrary Read/Write in kernel space and invoke Arbitrary Kernel Function Calls and obtain the return values. Moreover, they can perform all these actions in kernel space cleanly for unlimited times from separate task contexts. In other words, the boundary between the user space and the kernel space is completely broken. 5 RETSPILL VS MODERN DEFENSES In this section, we state how RetSpill manages to bypass a series of modern defenses in the Linux kernel. These defenses cover all existing protections deployed in kernels shipped in major Linux- based operating systems (listed in Table 3). We also evaluate the effectiveness of emerging protections that are not implemented, Defense CFHP RetSpill Deployed? † Achievable? Works? SMEP/SMAP/KPTI ✓ ✓ ✓ RANDKSTACK ✓ ✓ ✓ STACKLEAK ✓ ✓ ✗ FG-KASLR ✓ ✓ ✗ KCFI/IBT ✓ ✓ ✗ Shadow Stack* ✓ ✓ ‡ ✗ CFI+Shadow Stack* ✗ ✗ ✗ Table 2: RetSpill’s applicability against all modern defenses. * Shadow Stack is unavailable in Linux on x86_64 architecture. † Whether the defense is deployed in at least one of the major Linux distros mentioned in Table 3. ‡ RetSpill works with restrictions. OS Version Status Ubuntu 22.04 ✗ Debian 11 ✗ CentOS 9 ✓ Fedora 36 ✗ Arch Linux 2022.10.01 ✗ Mageia 8 ✗ Mint 21 ✗ Open SUSE Leap 15.4 ✗ Table 3: The panic_on_oops configuration in major Linux- based operating systems. not production-ready, or not deployed yet. A brief summary can be found in Table 2. SMEP/SMAP/KPTI. These protections aim to prevent attackers from directly accessing user space data when obtaining CFHP in kernel space. But RetSpill does not rely on data in the user space. Instead, it solely relies on user-controlled data on the kernel stack. In other words, RetSpill shows that user-controlled data on the kernel stack alone is enough to compromise the security of the full system, thus bypassing these three protections. RANDKSTACK. RANDKSTACK [53] introduces a randomized offset between function stack frames and the pt_regs region as shown in Figure 1. This protection aims to randomize the kernel stack layout at each system call entry to prevent deterministic data control on the kernel stack when CFHP is obtained. However, this protection only mitigates attacks that access data spillage from Preserved Registers and Uninitialized Memory. Attackers can still deterministically access controlled data spilled by Valid Data and Calling Convention because they are part of the stack frames. Moreover, we discover that Preserved Registers data spillage can still be used for exploitation despite the presence of this protection. Due to the low entropy (5-bit [53]) in the randomized offset of the current design, attackers can hardcode an offset and prepend a “ret- sled” (a series of ret gadgets) to the actual ROP chain to increase the chance of executing the actual ROP payload correctly. More importantly, if the target system disables panic_on_oops, which is true by default for most major Linux-based operating Taint Analysis System Call Snapshot Data Spillage Analysis ROP Chain Generation IGNI Kernel Image CFHP PE Exploits Figure 2: IGNI Design Overview systems, as shown in Table 3, RANDKSTACK can be fully bypassed. In other words, RetSpill can bypass RANDKSTACK on most of the Linux distros. The reason is that with panic_on_oops disabled, an oops in task contexts will not crash the kernel. By using threads to trigger the payload, if an attempt fails, only the offending thread will be terminated. The exploit process will be kept intact and can continue attempts until the exploit succeeds. Such a create-thread- and-retry attack works only if failed attempts only generate oops and do not crash the kernel. We demonstrate that this is realistic— by calling a system call that is known to place “safe" data, such as NULL pointers, on the kernel stack multiple times to ensure that failed attempts can only trigger invalid-memory access and generate oops. To the best of our knowledge, we are the first to demonstrate that RANDKSTACK can be fully bypassed through recovery from oops. STACKLEAK/STRUCTLEAK/INITSTACK. These protections prevent attackers from accessing uninitialized memory. More specif- ically, STACKLEAK [50] clears the kernel stack after each system call and INITSTACK [51]/STRUCTLEAK [43] ensure stack variables are initialized before use. In other words, they only prevent user data spillage from Uninitialized Memory. RetSpill is still effective by using other user data spillage methods to obtain stack control. FG-KASLR. Function Granular Kernel Address Space Layout Randomization (FG-KASLR) [34] shuffles all kernel function ad- dresses during boot time to protect the kernel from CFH attacks. However, function-level randomization is not enough to mitigate RetSpill. Other code snippets, such as assembly stubs, can also be compiled into executable sections with fixed offsets in the kernel. With RetSpill, attackers can look for ROP gadgets in the position- invariant code and use the arbitrary-read primitive to dynamically resolve function addresses, as demonstrated by Dang Khac Minh Le [38]. Then they can trigger the payload again and use the re- solved function addresses to achieve the exploitation using RetSpill. KCFI/IBT. KCFI [60] and Indirect Branch Tracking (IBT) [76] are two control-flow integrity (CFI) protection schemes merged into the Linux kernel recently. They both aim to protect the Linux kernel from forward-edge control-flow hijacking attacks. While they make it harder, they do not eliminate CFHP attacks. Due to compatibility issues, even with the presence of these strong protections, some call targets in the Linux kernel are still not protected, susceptible to CFHP attacks. For example, in a ker- nel compiled with KCFI, __efi_call function does not verify its call targets. An attacker can overwrite the call target and obtain PC-control. We confirmed with the Linux kernel team that some call targets are not verified due to incompatibility between some subsystems and the CFI schemes. Even with perfect implementation, attackers can still obtain PC- control by hijacking backward-edge control flow because KCFI/IBT does not protect them. For example, attackers have demonstrated the capability of turning a heap-based vulnerability to the kernel stack (dubbed kernel stack overflow primitive) [30], which can tamper the backward-edge control flow to obtain PC-control. Once PC-control is obtained, attackers can carry out RetSpill despite the presence of KCFI and IBT because RetSpill itself does not rely on forward-edge control-flow hijacking. Shadow Stack. Shadows Stack is proposed to protect backward- edge control in the Linux kernel. However, it is not implemented yet in the Linux kernel for the x86_64 architecture. We only analyze its security guarantee against RetSpill in theory. In kernels protected by Shadow Stack, attackers can obtain PC-Control from forward- edge control flow hijacking, but they cannot ROP. To carry out RetSpill, attackers can use other code reuse attacks that do not rely on backward-edge control flow hijacking, such as JOP[3]/PCOP[55] to utilize data spillage from user space, CFI+Shadow Stack. In theory, on a kernel deployed with per- fectly implemented CFI schemes and Shadow Stack, attackers can- not obtain CFHP anymore, which prevents RetSpill. 6 SEMI-AUTOMATIC RETSPILL RetSpill has a critical impact on the Linux kernel because it can not only escalate privilege but also has the potential to achieve the escalation in a semi-automated pipeline. To show the feasi- bility of semi-automation, we represent IGNI, a framework that can semi-automatically generate RetSpill attacks for many real- world CFH cases. As the goal of this work is to show the feasibility rather than creating a tool to facilitate malicious attacks, we only take one attack payload for privilege escalation, namely execut- ing commit_creds(init_cred) and returning back to user space gracefully. Creating attacking tools that can comprehensively lever- age different attack vectors is out of the scope of this paper. The design of IGNI is shown in Figure 2. IGNI takes a proof-of- concept (PoC) binary that demonstrates CFHP and a target kernel image as input, and outputs all the information needed for carrying out RetSpill. More specifically, it outputs 1) the address of a stack- shifting gadget that can transfer the initial CHFP into kernel stack and 2) an ignite function that performs data spillage, invokes the triggering system call, and leads to PE automatically. By setting the initial CFHP to the stack-shifting gadget and changing the original triggering system call to ignite function, the initial crashing PoC is turned into a full-fledged PE exploit. Our approach relies on virtual machine (VM) snapshots. We take a VM snapshot when the triggering system call just enters kernel space, which ensures deterministic CFHP. Then, we analyze all user |