1 / 16

kGuard : Lightweight Kernel Protection against Return-to-User Attacks

kGuard : Lightweight Kernel Protection against Return-to-User Attacks. Authors: Vasileios P. Kemerlis Georgios Portokalidis Angelos D. Keromytis Presenter: Behnaz Hassanshahi. Problem Statement. Kernel exploitation Kernel-level memory corruption

elin
Télécharger la présentation

kGuard : Lightweight Kernel Protection against Return-to-User Attacks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. kGuard: Lightweight Kernel Protection against Return-to-User Attacks Authors: VasileiosP. KemerlisGeorgiosPortokalidis Angelos D. Keromytis Presenter: BehnazHassanshahi

  2. Problem Statement • Kernel exploitation • Kernel-level memory corruption • Traditionally: Code injection – (Code Reuse)ROP • Recently: Run user land code (ret2user attacks)

  3. Return to User Attacks • The root problem stems from the weak separation of user and kernel spaces. • Shared process/kernel model for Performance benefits • Kernel code can do anything in user land, so if it is abused, attacker can force it to run the shell code in user space. • Over-writing kernel-level control data(e.g., return addresses, jump tables, function pointers) with user space addresses.

  4. Return to User Attacks • Example: exploiting a NULL pointer dereference error to launch a ret2user attack Vulnerable program

  5. Return to User Attacks • malicious process invokes “sendfile” system call with offending arguments • libc wrapper traps to the OS via “sysenter” • system call handler of Linux (sysenter_do_call()) is executed which resolves the kernel address of sys-sendfile • Privileged execution continues until sock_sendpage() is invoked • the value of sendpage pointer is NULL • control is transferred to address 0 • malicious process has mmapped page 0 and dropped a function pointer of his own at address 0, the kernel will call that function pointer in kernel mode

  6. Existing Defense Mechanisms • CFI and Program Shepherding • PAX • Mmap_min_addr • Intel SMEP • Doesn`t prevent kernel from accessing user “data”

  7. kGuard • Inline monitoring and code diversification • Adding “Control Flow Assertions” at compile time before every indirect control transfer • E.g., call, jmp and ret in x86 • CFAR: compares the branch target with lower kernel address 0xC00000 • CFAm: • Branch target is within the kernel address space • Memory address where the branch target is loaded from is also in kernel space

  8. kGuard • Example CFA guard

  9. Bypassing kGuard • Bypass trampolines 1. Find two computed branch instructions whose operands can be reliably overwritten 2. Overwrite the value (branch target) of the first with the address of the second 3. Overwrite the value of the second with a user-space address 4. Solution: Code inflation and CFA motion

  10. Code Inflation • Reshapes the Kernel text at at compile time

  11. CFA Motion Relocation of protected branches at boot time

  12. Implementation • The implementation consists of a pluginfor GCC. • At RTL level, after most of the important optimizations

  13. Effectiveness on Privilege Escalation Attacks

  14. Performance Evaluation

  15. Performance Evaluation – latency overhead and code diversification

  16. Conclusion and Discussion • In near future all memory regions will be randomized • Randomization of the address at which kernel is loaded • Intel SMEP vskGuard • Performance • Side channel attacks

More Related