lightweight virtualization framework protects critical kernel objects from rootkits
•
1 like•597 views
A lightweight invariance-enforcing framework to mitigate rootkits in virtualized operating systems
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to lightweight virtualization framework protects critical kernel objects from rootkits
Similar to lightweight virtualization framework protects critical kernel objects from rootkits (20)
Recently uploaded
Recently uploaded (20)
lightweight virtualization framework protects critical kernel objects from rootkits
- 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 will never be solved the problem
- 7. FACT
- 8. FACT “I’d rather tackle world peace than the rootkit problem, it is that hard to solve”
- 9. ATTACKER MODEL Loading rootkit as 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 kernel data 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_CR event :-| 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 objects to 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 and Linux 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 to variant data structures are still possible
- 21. DISCUSSION Kernel developers support system Fine-grained protection Lightweight contermeasure Guarantees target-monitor isolation
- 22. DEMO.
- 23. CONCLUSION helloRootkitty mitigates the problem of kernel malware Negligible overhead Attack surface might be considerably reduced Easy integration with other protection mechanisms (Daikon, Gibraltar)
- 24. THANKS.