HITBSecConf 2017-Shadow-Box-the Practical and Omnipotent Sandbox
0 likes207 views
The document presents Shadow-Box, a lightweight hypervisor-based kernel protector designed for real world deployment. Shadow-Box uses virtualization technology to separate the machine into a secure host (Ring -1) and normal guest (Ring 0-3). It shares kernel memory between the two worlds to reduce overhead. The host can monitor the guest to detect rootkits and other attacks modifying kernel objects or function pointers. The author discusses lessons learned from deploying Shadow-Box, such as handling mutable kernel code and properly configuring cache types in the extended page table.
HITBSecConf 2017-Shadow-Box-the Practical and Omnipotent Sandbox
- 1. Shadow-Box: The Practical and Omnipotent Sandbox Seunghun Han hanseunghun@nsr.re.kr
- 2. - Senior security researcher at NSR (National Security Research Institute of South Korea) - Speaker at HITBSecConf 2016 and Black Hat Asia 2017 Who am I ? - Author of the book series titled “64-bit multi- core OS principles and structure, Vol.1&2” - a.k.a kkamagui, @kkamagui1
- 3. Goal of This Presentation - I present lightweight hypervisor-based kernel protector, “Shadow-box” - I share lessons learned from deploying and operating Shadow-box in real world systems - I introduce the future plan, “Shadow-box v2” which can support ARM and x86 platform
- 4. Background Design Implementation Lessons Learned and Demo. Future Work and Conclusion
- 5. Linux Kernel Is Everywhere!
- 6. Security Threats of Linux Kernel - The Linux kernel suffers from rootkits and security vulnerabilities - Rootkits: EnyeLKM, Adore-ng, Sebek, suckit, kbeast, and so many descendants - Vulnerabilities: CVE-2014-3153, CVE-2015-3636, CVE-2016-4557, CVE-2017-6074, etc. Devices which use Linux kernel share security threats
- 7. Melee Combats at the Kernel-level - Kernel-level (Ring 0) protections are not enough - Lots of rootkits and exploits work in the Ring 0 level - Protections against them are often easily bypassed and neutralized - Kernel Object Hooking (KOH) - Direct Kernel Object Manipulation (DKOM) Protections need an even lower level (Ring -1)
- 8. Well-known Rootkits Other rootkits also have similar patterns
- 9. Taking the Higher Ground - Leveraging virtualization technology (VT) - VT separates a machine into a host (secure world) and a guest (normal world) - The host in Ring -1 can freely access/control the guest in Ring 0 (the converse doesn’t hold) - VT-equipped HW: Intel VT-x, AMD AMD-v, ARM TrustZone
- 10. UserUser Trends of Introducing Ring -1 User Kernel Guest (Normal World) Host (Secure World) Host OS Guest OS User Kernel Virtualization Technology (T.Z., VT-x, AMD-v) Monitor, control
- 11. Previous Researches… OH, NO… TOO MANY…
- 12. Researches Are Excellent, But They Look … I heard and knew about them But, I can not find in real world!
- 13. - Many researches have preconditions - They usually change kernel code or hypervisor - They also need well-known hashes of LKM, well-known value of kernel data, secure VM for analyzing target VM, etc. - Many researches consume much resource - The host and the guest run each OS - They allocate resources independently! - The host consumes many CPU cycles to introspect the guest because of semantic gap Restrictions on Previous Researches (1)
- 14. Restrictions on Previous Researches (2) - In conclusion, previous researches are considered for laboratory environment only - They assume they can control environment! - But, real world environment is totally different from laboratory environment! - You even don’t know the actual environment before the software is installed! REAL WORLD! WELCOME TO
- 15. Therefore, PRACTICAL and LIGHTWEIGHT mechanism is needed for REAL WORLD ENVIRONMENT!
- 16. Design Goals of Kernel Protector - Lightweight - Focus on rootkit detection and protection - Simple and extensible architecture - Small memory footprint - No secure VMs and no multiple OSes - Practical - Out-of-box approach - No modification of kernel code and data - Dynamic injection - Load any time from boot to runtime
- 17. Background Design Implementation Lessons Learned and Demo. Future Work and Conclusion
- 18. Security Architecture in Shadow Play Bulb Actors Audience
- 19. Security Architecture in Shadow Play Ring -1 Monitoring Mechanism Activities in OS Security Monitor I named this architecture “Shadow-box” (Light-Box) (Shadow-Watcher)
- 20. User Shared Area Light-Box (Lightweight Hypervisor) Architecture of Shadow-Box User (Read/Write Permission) Shared Kernel (Read-only Permission) Guest (Ring 0~3)Host (Ring -1) Shared Kernel Only Shared Kernel and User Shared Kernel (Read/Write Permission) Shadow- Watcher (Monitor) Monitor, control
- 21. - Light-box, lightweight hypervisor, - Isolates worlds by using memory protection technique in VT - Shares the kernel area between the host (Ring -1) and the guest (Ring 0 ~ 3) - Does not run each OS in two worlds - Uses smaller resources than existing mechanisms and has narrow semantic gap - Can be loaded any time (loadable kernel module) Architecture of Light-Box
- 22. - Shadow-watcher - Monitors the guest by using Light-box - Checks if applications of the guest modify kernel objects or not by event-driven way - Code, system table, IDT table, etc. - Checks the integrity of the guest by introspecting kernel object by periodic way - Process list, loadable kernel module (LKM) list, function pointers of file system and socket Architecture of Shadow-Watcher
- 23. What can Shadow-Box do? - Shadow-box protects Linux kernel from - Static kernel object attacks - Static kernel object = immutable in runtime - Code modification and system table modification attacks - Dynamic kernel object attacks - Dynamic kernel object = mutable in runtime - Process hiding and module hiding - Function pointer modification attacks
- 24. Background Design Implementation Lessons Learned and Demo. Future Work and Conclusion
- 25. Boot Process using Shadow-Box Starting UEFI with Secure Boot Starting Bootloader Starting Linux Kernel Preparing Virtualization Separating and Starting the Guest Monitoring the Guest Starting Linux Applications Guest (Normal World) : Linux : Shadow-Box - Enabling VMX (Virtual Machine Extension) - Setting VMCS (Virtual Machine Control Structure) - Identifying kernel information - Separating memory area - Launching VMCS Host (Secure World) Loading Shadow-Box
- 26. Static Kernel Object Protection (1) User Area Static Kernel Objects Shadow- Box Objects Host Physical Address Level.3 Level 4 Level 3 Level 2 Level 1 Paging Structure of EPT Level.2 Level.1 Physical Physical Physical VT-x Extended Page Table (EPT) CPU Guest Physical Address Read, Write, Execute Read, Execute No Permission
- 27. Static Kernel Object Protection (2) Read, Execute Read, Execute Read, Execute Read, Execute No Permission Read, Execute Guest Page Table (GPT) Extended Page Table (EPT) Page 1 Page 2 Page 3 Guest Logical Address (GLA) Guest Physical Address (GPA) Host Physical Address (HPA) Page 1 Page 2 Page 3 Page 1 Page 2 Page 3 Guest (Normal World) Address Translation (Ring 0) Host (Secure World) Address Translation (Ring -1)
- 28. Static Kernel Object Protection (3) Read, Execute Read, Execute Read, Execute No Permission Guest Page Table (GPT) Extended Page Table (EPT) Page 1 Page 2 Guest Logical Address (GLA) Guest Physical Address (GPA) Host Physical Address (HPA) Page 1 Page 1 Page 2 Page 3 EPT protects the host from attack propagation of the guest Guest (Normal World) Address Translation (Ring 0) Host (Secure World) Address Translation (Ring -1) Read, Execute Read, Execute Page 3 Page 2 Page 3 Write, Execute Read, Execute Page 3 Page 2 Page 3
- 29. Static Kernel Object Protection (4) User Area Static Kernel Objects Shadow- Box Objects DMA VT-d DMA Remapping Reporting (DMAR) Table Physical Address DMA Address Read, Write No Permission No Permission Level.3 Level 4 Level 3 Level 2 Level 1 Paging Structure of Second Level Page Table Level.2 Level.1 Physical Physical Physical context Root Table Level.4 Context Table
- 30. Dynamic Kernel Object Protection (1) A B F... Next Prev Next Next Prev Prev Task and Module List in Guest ⑤ Comparing data Task and Module Create Function do_fork() or load_module() { create_object(); modify_list(); } Task and Module Delete Function release_task() or delete_module() { delete_object(); modify_list(); } ② Inserting H/W breakpoint ③ Monitoring Task and Module List in Shadow-box① Creating initial data A B F... Next Prev Next Next Prev Prev ④ Shadowing list data
- 31. VFS and Socket Objects of Guest FP Pointer Host Logical Address Module Code Malicious Code Open Function Pointer Structure Read Write Close Kernel Code ... Invalid Invalid Valid Valid Malicious Code (Loaded after Shadow-box) User Area Kernel Area Dynamic Kernel Object Protection (2) : Code area loaded before Shadow-box
- 32. Privileged Register Protection - GDTR, LDTR and IDTR change interactions between kernel and user level - IA32_SYSENTER_CS, IA32_SYSENTER_ESP, IA32_STAR, IA32-LSTAR and IA32_FMASK MSR also change them - These privileged registers are rarely changed after boot! - So, Shadow-box - Locks the privileged registers - Locks and Monitors GDT, LDT, and IDT table
- 33. Rootkit Detection - All rootkits are detected Name Detected? Detected Point EnyeLKM √ code change, module hide Adore-ng 0.56 √ function pointer change, module hide Sebek 2.0 √ system table change, module hide Suckit 2.0 √ system table change kbeast √ system table change, module hide
- 34. Performance Measurements of Prototype - Application benchmarks show 1% ~ 10% performance overhead - 5.3% at kernel compile in single-core processor - 6.2% at kernel compile in multi-core processor Results of Application Benchmark. Lower is better. (Intel i7-4790 4core 8thread 3.6GHz, 32GB RAM, 512GB SSD) Single-core processor Multi-core processor
- 35. Background Design Implementation Lessons Learned and Demo. Future Work and Conclusion
- 36. Ready to launch! I deployed Shadow-box in REAL WORLD! and …
- 37. I met BEASTS of REAL WORLD! (false positive, slow-down, system hang, etc.) Previous researches did not tell us something important! AGAIN! NICE TO MEET YOU WHAT HAPPENED… OH, NO…
- 38. Lessons Learned - 1 - Code is not immutable! - Linux kernel has a CONFIG_JUMP_LABEL option! - If this option is set, Linux kernel patches itself on runtime! - Unfortunately, this option is set by default! - Solution - Option 1: Add exceptional cases for mutable code pages - Option 2: If you can build kernel, Turn Off CONFIG_JUMP_LABEL option NOW!
- 39. Lessons Learned - 2 - Cache type in EPT is very important! - Linux system has some memory mapped I/O area - BIOS area, APIC area, PCI area, etc. - Misconfiguration makes various problems such as system hang, slow down, video mode change error, etc. - Solution - Set uncacheable type by default - Set write-back type to “System RAM” area only!
- 40. Lessons Learned - 2 Write-back Cache Type Uncacheable Cache Type by Default
- 41. Lessons Learned - 3 - Multi-core environment is more complicated than you think! - Each core modifies process list and module list concurrently - When H/W breakpoint exception occurred, other cores could be changing the lists already! - So, I need a mechanism for synchronizing lists - Solution - Lock tasklist_lock and module_mutex of the guest while Shadow-box is checking the lists!
- 42. Now, I have been operating Shadow-box in REAL WORLD SUCCESSFULLY !
- 43. DEMO
- 44. Background Design Implementation Lessons Learned and Demo. Future Work and Conclusion
- 45. Future Work X86 VT-x, VT-d (Virtualization Technology) Shadow-Box Linux TrustZone (Virtualization Technology) Shadow-Box Linux Multi-platform Support!
- 46. SMC call (System Monitor Call) Light-Box (Trusted Kernel and Trusted App.) Coming Soon!: Shadow-Box for ARM User Application Normal Kernel Normal World (Ring 0~3)Secure World (Ring -1) Trusted Kernel Shadow- Watcher (Trusted App.) Monitor, control Shadow- Watcher Client
- 47. Conclusion - Kernel-level (Ring 0) threats should be protected in a more privileged level (Ring -1) - I create Ring -1 level by using VT from scratch - Shadow-box is lightweight and practical - Shadow-box uses less resource than existing mechanisms and protects kernel from rootkits - Real world is Serengeti! - Real world is different from laboratory environment - You should have a strong mentality for defeating beasts of real world! or use Shadow-box instead!
- 48. Contact: hanseunghun@nsr.re.kr, @kkamagui1 Project : github.com/kkamagui/shadow-box-for-x86 DEFEATING REAL WORLD BEASTS ! CONTRIBUTIONS FOR