RetSpill: Igniting User-Controlled Data to Burn Away Linux Kernel Protections
tải về 0.65 Mb. Chế độ xem pdf
|
| Random Offset
… Figure 5: Unhardened and Hardened Stack Frames. stack to carry out malicious payload through ROP. We demonstrate RetSpill’s ability to bypass KCFI/IBT with experiments 3 . FG-KASLR. We contacted the authors of FG-KASLR and ob- tained its latest source code. Similar to the setup in RANDKSTACK, we compile the kernel with default configuration with FG-KASLR enabled. We write a tool to parse the kernel’s FG-KASLR-related metadata and extract a position-invariant region of 4MB from the kernel image we build. As mentioned in §5, this region consists of executable code that is not within the boundary of any functions (e.g., manually written assembly stubs). In total, we obtained 42631 unique gadgets from the position-invariant region, which is more than enough for dynamically resolving kernel function address. We succeed in using RetSpill to perform privileged escalation against the kernel compiled with FG-KASLR using the vulnerability in the contrived kernel module. Case study: Breaking Security Boundary. We demonstrate the ability of RetSpill to break the security boundary between user space and kernel space using a real-world example. We implement an end- to-end proof-of-concept exploit for CVE-2022-1786 that performs Arbitrary Read/Write in kernel memory and Arbitrary Function Call in one single exploit by only changing the payload on the stack. Besides the individual primitives, this experiment also confirms RetSpill’s ability to provide unlimited Arbitrary Read/Write/Exec primitive. In our analysis, Independent ROP Chain proves to be vital in obtaining CFHP multiple times. This is because, in this specific exploit, CFHP is obtained after the exploit thread acquires a lock. Since the control flow returns back to user space without releasing the lock, if we try to obtain CFHP again in the same thread, the exploit will stop indefinitely waiting for the lock to be released. Independent ROP Chain provided by RetSpill avoids the locking issue because each CFHP is obtained in a different thread. 8 DEFENSE In this section, we explore plausible protections against RetSpill besides CFI+Shadow Stack, which is not ready yet and requires special hardware. To mitigate this exploitation technique, the key is to eliminate all data spillage on the kernel stack. Preserved Register. RANDKSTACK is the only existing protec- tion that mitigates Preserved Register data spillage. It comes with near-zero performance overhead [17] but offers probabilistic pro- tection. In our experiment, exploits can still have a 25.44% chance of succeeding against kernels with this protection. Moreover, this 3 https://github.com/sefcom/RetSpill/tree/main/experiments/kcfi_eval protection should be coupled with panic_on_oops, or it can be fully bypassed (§7.3). To completely mitigate this data spillage, we suggest preserving user space registers elsewhere instead of on the kernel stack. For example, the registers can be saved in the asso- ciated task’s task_struct data structure. This way, even if CFHP is obtained by attackers, user space registers will not be directly accessible on kernel stacks to facilitate further exploitation. Uninitialized Memory. For Uninitialized Memory data spillage, all STACKLEAK, STRUCTLEAK, INITSTACK, and RANDKSTACK can provide different levels of protection. STACKLEAK clears the kernel stack after each system call, which ensures zero usable Unini- tialized Memory data spillage when CFHP is obtained. However, STACKLEAK has an average overhead of more than 40% [44]. INIT- STACK and STRUCTLEAK use compilers’ pattern initialization feature to initialize stack variables, which also ensures no Unini- tialized Memory data spillage while having only a performance overhead of 2.7%-4.5% [72]. As mentioned above, RANDKSTACK has near-zero performance overhead but only provides probabilistic protection. Considering protection and performance, we suggest enabling INITSTACK or STRUCTLEAK to avoid Uninitialized Mem- ory data spillage on kernel stack. Calling Convention and Valid Data. The latest version of the Linux kernel has deployed a protection that clears user space registers that are not part of the ABI in the system call entry stub. As shown in Table 4, new kernel builds have significantly less data spillage caused by Calling Convention compared with old kernel builds because of this protection. However, data spillage caused by Calling Convention is still not eliminated. Data spillage caused by Valid Data and Calling Convention is tải về 0.65 Mb. Chia sẻ với bạn bè của bạn:
|