Uploaded byFrancesco Gadaleta
Hello rootKitty: A lightweight invariance-enforcing framework
This document proposes a lightweight framework called helloRootkitty that enforces kernel integrity using virtualization. It traps events like control register changes to check the integrity of critical kernel objects. When it detects compromised objects, it can repair them if the original values are known. Evaluation on BitVisor showed it introduces minimal overhead while reducing the attack surface for rootkits compared to traditional approaches.
More Related Content
Similar to Hello rootKitty: A lightweight invariance-enforcing framework
Hello rootKitty: A lightweight invariance-enforcing framework
- 1. hello rootKitty a lightweight invariance-enforcing framework Francesco Gadaleta - Nick Nikiforakis DISTRINET Research Group Katholieke Universiteit Leuven - Belgium
- 2. hello rootKitty a lightweight invariance-enforcing framework Francesco Gadaleta - Nick Nikiforakis DISTRINET Research Group Katholieke Universiteit Leuven - Belgium
- 3. OVERVIEW rootkit Operating System framework critical kernel objects malware detection code virus Analysis integrity invariance attack module virtualization malicious repairing memory corruption approach profiling hardware-based countermeasure evaluation
- 4. ๏ process hiding ๏botnet ๏ stealing private data ROOTKIT ๏ subverting kernels ๏ spamming ๏ bank fraud
- 5. ROOTKIT User-mode ls, ps, PATH, etc... limited to user’s privileges Kernel-mode device drivers, access to kern. memory, etc... limited to kernel’s privileges (=unlimited)
- 6. FACTof rootkits willnever be solved the problem
- 7.
- 8. FACT “I’d rather tackleworld peace than the rootkit problem, it is that hard to solve”
- 9. ATTACKER MODEL Loading rootkitas LKM Loading by overwriting memory directly (eg. /dev/mem, /dev/kmem) Executing arbitrary code via kernel vulnerability GOAL: Compromission of hardcoded, static, dynamic kernel objects
- 10. VIRTUALIZATION Events trapped by the hypervisor case EXIT_REASON_MOV_CR case EXIT_REASON_CPUID case EXIT_REASON_IO_INSTRUCTION case EXIT_REASON_RDMSR case EXIT_REASON_WRMSR Guest kernel case EXIT_REASON_EXCEPTION_OR_NMI case EXIT_REASON_EXTERNAL_INT case EXIT_REASON_INTERRUPT_WINDOW case EXIT_REASON_INVLPG case EXIT_REASON_VMCALL: /* for debugging */ case EXIT_REASON_INIT_SIGNAL case EXIT_REASON_STARTUP_IPI case EXIT_REASON_HLT VMExit VMEntry case EXIT_REASON_TASK_SWITCH case EXIT_REASON_XSETBV guest memory space hypervisor memory space Hypervisor
- 11. ASSUMPTION Rootkits modify kerneldata structures Observing critical kernel objects is a good detection strategy Virtualization still not massively exploited in desktop environments (QubesOS)
- 12. APPROACH Phase 1: collecting addresses of data structures to protect phy s ad 0xC dr 1 234 0xC 567 size 3214 0xC 567 128 flag 421 s 456 128 111 0xC A 111 521 11 456 111 C 64 111 11 111 4 111 11 guest kernel 111 111 11 trusted module guest memory space hypervisor memory space hypervisor
- 13. APPROACH Phase 2: check integrity within the hypervisor mem. space guest kernel guest memory space hypervisor memory space hypervisor phys addr size hash 0xC1234567 128 abcd 0xC3214567 128 abde 0xC421456A 64 1234 0xC521456C 4 4321
- 14. APPROACH Phase 3: repair compromised objects (if original content provided) guest kernel guest memory space hypervisor memory space hypervisor phys addr size hash 0xC1234567 128 abcd 0xC3214567 128 abde 0xC421456A 64 1234 0xC521456C 4 4321
- 15. IMPLEMENTATION Exploit the MOV_CRevent :-| App 1 App 2 App 3 (1) When the guest kernel changes a <mov CR3, cr3_app2> scheduler control register it is doing Guest something “interesting” such as kernel task switching :-) (2) guest memory space hypervisor memory space Room for improvement: we can hypervisor (3) map all the objects to a common host_virt_space area in the hypervisor’s space and phys addr size hash 0xC1234567 128 abcd compute the checksum once 0xC3214567 0xC421456A 128 64 abde 1234 0xC521456C 4 4321
- 16. IMPLEMENTATION Lists of objectsto protect might be HUGE => let’s relax the problem phys addr size hash <mov CR3, cr3_app1> <mov CR3, cr3_app2> <mov CR3, cr3_app3> SOLUTION: <mov CR3, cr3_app4> on MOV_CR event the hypervisor checks a subset of objects $$
- 17. EVALUATION BitVisor 1.1 andLinux Kernel 2.6 Total: 15000 kernel objects 128-bit sized Rate: 100 objects/MOV_CR* Corruption of pointers in the guest system call table
- 18. PERFORMANCE LMBENCH (microbenchmarks) Processes open/close sign. handl. fork exec +0.6% +2.5% +41% +35% Local comm. TCP File reread Mmap reread Bcopy Mem.read Mem. write bandwidths +2.2% 0% -0.9% -0.32% -0.12% 0.12%
- 19. PERFORMANCE APACHEBENCH 100K requests,50 concurrently on local lighttpd server (macrobenchmarks) Time +1.50% Req. per second +1.52% Time per request +1.54% Time per conc. req +1.4% Transfer rate +1.52% DETECTION TIME (time the hypervisor needs to check a compromised object in the worst case) Depends on the guest load, about 6 sec wall-clock time
- 20. LIMITATIONS Protects invariants Attacks tovariant data structures are still possible
- 21. DISCUSSION Kernel developers supportsystem Fine-grained protection Lightweight contermeasure Guarantees target-monitor isolation
- 22.
- 23. CONCLUSION helloRootkitty mitigates theproblem of kernel malware Negligible overhead Attack surface might be considerably reduced Easy integration with other protection mechanisms (Daikon, Gibraltar)
- 24.