RetSpill: Igniting User-Controlled Data to Burn Away Linux Kernel Protections
int __sys_recvfrom (...) 2 { 3 struct
tải về 0.65 Mb. Chế độ xem pdf
|
| int
__sys_recvfrom (...) 2 { 3 struct sockaddr_storage address; 4 ... 5 // initialize `address` 6 sock -> ops -> recvmsg(...); 7 ... 8 // copy address to user space 9 copy_to_user(uaddr, & address, ulen); 10 } Listing 2: The simplified code snippet of recvfrom system call handler in the Linux kernel. hijacking control flow can create unexpected uninitialized memory situations on the kernel stack that would not be a security problem in normal operation and could result in a considerable number of usable data from the attackers’ perspective. An attacker can then carry out a targeted stack spray attack [45] to place controlled data on specified stack locations. As shown in Listing 2, the address variable will be initialized inside the target socket’s recvmsg handler, which means it will always be initialized and copied to user space in the normal con- trol flow. But if the sock data structure is fully overwritten by an attacker through a vulnerability, when CFHP is obtained at sock->ops->recvmsg , the address variable is not initialized, thus susceptible to the targeted stack spray attack. 4.3 Weaponizing Spilled User Space Data After obtaining enough data spillage on the kernel stack, the mo- ment an attacker invokes the triggering system call and acquires CFHP, they have stack control as well. In other words, the attacker can immediately launch code reuse attacks. In this work, we focus on executing a ROP payload. Starting ROP. In the optimal case, the stack pointer might be pointing directly to user-controlled data when the CFHP is triggered. However, even if it is not, the typical proximity of user-controlled data to the stack pointer means that the attacker can “reach” it by using the CFHP to redirect execution to a stack-shifting gadget such as add rsp, X; ret. After this redirection, the attacker’s ROP chain, stored in user-controlled portions of the kernel stack, will be triggered. Small Chains. However, the initial ROP payloads enabled by RetSpill are too small for full exploits. This is due to three factors. First, different triggering system calls exhibit different data- spilling behaviors depending on how they process userspace data. While the amount of Preserved Registers is stable across different system calls, the amount of Valid Data, data spilled due to Calling Conventions, and Uninitialized Memory varies widely. Second, the CFHP itself might require specific inputs in some registers and memory to trigger successfully. For example, trigger- ing the CFHP for CVE-2010-2959 requires a specific value in the fd argument (passed via the rdi register) to the triggering ioctl sys- tem call. This means that spilled values from rdi, regardless of the spillage method, cannot be used in the ROP chain (as they cannot have arbitrary values). Other vulnerabilities require more argu- ments to have precise values, reducing the amount of controllable spilled data further. Third, spilled user space data is not contiguous, and thus some of the resulting gadgets must be dedicated to shifting the stack to the next controllable spilled data. With resulting ROP chains as short as 7 gadgets (as measured in tải về 0.65 Mb. Chia sẻ với bạn bè của bạn:
|