Introduction

I’d like to talk about the ret2usr attack in Linux kernel exploitation and the corresponding Supervisor Mode Execution Prevention (SMEP). Rather than detailing the exploitation details in control flow hijacking, this post will explain what is ret2usr attack and what is the expected behaviour from SMEP.

ret2usr attack

ret2usr (return-to-user) attack exploits the truth that the code in kernel mode (high memory) can execute the code in user mode (low memory).
In the exploitation of CVE-2017-7308, we choose to overwrite the packet_sock->rx_ring->prb_bdqc->retire_blk_timer->func, whose offset in packet_sock structure is 1274.
The final result is given below:

We can find that the execution flow jumps to the code in user mode (0x0000560b96e4eb20) and executes the function prepared by attacker. The full code can be found on my github repo[3].

SMEP

SMEP is kernel protection against ret2usr attack. If the CPU is running in the ring0 mode, executing a code in user space will trigger a page fault.
To enable SMEP for guest machine in QEMU, one more option should be added as below:

qemu-system-x86_64   -s -cpu kvm64,+smep  \
-kernel /home/dango/Kernel/linux-4.10.6-build/arch/x86/boot/bzImage  \
-append "console=ttyS0 root=/dev/sda rw oops=panic panic=1 quiet"  \
-hda /home/dango/Kernel/Image01.img  \
-enable-kvm -m 2G -nographic

If we run the exploit code again, we will get the result as the cover page.

Conclusion

This post is pretty short. The exploit code on my github repo can execute the malicious code in the user mode but cannot spawn a shell in the end. I suspect that the kernel code may fall into some deadlock situation, I have no way to confirm that or debug that. Next I may try to use some other exploitation techniques to do some test.

Reference

[1] https://xz.aliyun.com/t/2054
[2] https://ctf-wiki.github.io/ctf-wiki/pwn/linux/kernel/bypass_smep/
[3] https://github.com/dangokyo/LinuxKernelExploit/blob/master/CVE-2017-7308/SmepPOC/hijack.c