SPIDER: Stealthy Binary Program Instrumentation and Debugging via Hardware Virtualization - PowerPoint PPT Presentation

spider stealthy binary program instrumentation and debugging via hardware virtualization n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
SPIDER: Stealthy Binary Program Instrumentation and Debugging via Hardware Virtualization PowerPoint Presentation
Download Presentation
SPIDER: Stealthy Binary Program Instrumentation and Debugging via Hardware Virtualization

play fullscreen
1 / 23
SPIDER: Stealthy Binary Program Instrumentation and Debugging via Hardware Virtualization
267 Views
Download Presentation
bern
Download Presentation

SPIDER: Stealthy Binary Program Instrumentation and Debugging via Hardware Virtualization

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. 29th ACSAC(December, 2013) SPIDER: Stealthy Binary Program Instrumentation and Debugging via Hardware Virtualization Zhui Deng, Xiangyu Zhang, and DongyanXu Department of Computer Science and CERIAS, Purdue University

  2. Outline • Introduction • Overview • Design • Implementation • Evaluation A Seminar at Advanced Defense Lab

  3. Introduction • The ability to trap the execution of a binary program at desired instructions is essential in many security scenarios. • malware analysis • attack provenance • However, existing approaches are insufficient to support transparent, efficient, and flexible instruction-level trapping. A Seminar at Advanced Defense Lab

  4. Related Work • In-Guest Approaches • Software Breakpoint (int 3), Hardware Breakpoint (DR0 ~ DR3) • Page-level mechanism • Dynamic Binary Instrumentation (DBI) • Emulation Based Approaches • Hardware Virtualization Based Approaches • Hybrid Approaches A Seminar at Advanced Defense Lab

  5. Overview • Our Goal • Flexibility • Efficiency • Transparency • Reliability A Seminar at Advanced Defense Lab

  6. Background about Memory Virtualization • Old Memory Virtualization A Seminar at Advanced Defense Lab

  7. Intel Extended Page Table (EPT) A Seminar at Advanced Defense Lab

  8. Another Figure for EPT A Seminar at Advanced Defense Lab

  9. Overview (cont.) A Seminar at Advanced Defense Lab

  10. Design – Splitting Code and Data View • Splitting Code and Data View • Spider splits the code and the data views of a guest physical page by mapping it to two host physical pages with mutually exclusive attributes. • Code view: executable, not readable, no writable. • Data view: not executable, readable, no writable. • Given a split page, although the corresponding EPT entry could only map one of its views at any given time, the mappings of the two views can exist simultaneously in the iTLB (instruction TLB) and dTLB (data TLB), respectively. A Seminar at Advanced Defense Lab

  11. Split View EPT Violation Physical Page 1 (Execute-Only) int 3 movebp, esp sub esp, 16 Execute iTLB Guest Page Table Extended Page Table A Seminar at Advanced Defense Lab Physical Page 2 (Read-Only) push ebp movebp, esp sub esp, 16 dTLB Read

  12. Design - Handling Breakpoints • Spider sets the hypervisor to intercept all #BP exceptions generated by the guest. • For single-stepping, Spider uses the monitor trap flag (MTF) which is a flag specifically designed for single-stepping in hardware virtualization. • the guest will trigger a VM Exit after executing each instruction. A Seminar at Advanced Defense Lab

  13. Design - Monitoring Virtual-to-Physical Mapping A Seminar at Advanced Defense Lab

  14. Design - Handling Code Modification • When the guest tries to write to the page, an EPT violation will be triggered and captured. A Seminar at Advanced Defense Lab

  15. Design - Data Watchpoint • Spider allows setting a data watchpoint at a specific physicaladdress. • adjusting the EPT entry of the guest physical page that contains the memory address to read-only (to trap write access) or execute-only (to trap both read/write access) A Seminar at Advanced Defense Lab

  16. Design - Handling Timing Side-Effect • To maintain transparency, Spider needs to hide the CPU cycles cost by hypervisor (Th) and VMEntry/VMExit (Te) from the guest. • Spider sets the TSC-offset field in virtual machine control structure (VMCS) to −(Th+ Te) so the value is subtracted from the TSC seen by the guest. A Seminar at Advanced Defense Lab

  17. Implementation • We have implemented a prototype of Spider on the KVM 3.5 hypervisor. • Kernel Breakpoints • We could specify the address space of any process as the kernel space is mapped in the same way for any process. • (init in Linux and System in Windows) • Monitor Process Creation • In Windows, we set a breakpoint at the instruction right after the call to PspCreateProcess. • In Linux, We set a breakpoint at the instruction right after the call to copy_process. A Seminar at Advanced Defense Lab

  18. Implementation (cont.) • Monitor Process Termination • In Windows, we set the breakpoint at the entry of the function PspProcessDelete. • In Linux, we set the breakpoint at the entry of the function do_exit. A Seminar at Advanced Defense Lab

  19. Evaluation • Environment • Hardware: Thinkpad T510 laptop with Intel Core i7-3720QM 2.6GHz CPU and 8GB RAM. • Host OS: Ubuntu Linux 12.10 64-bit • Guest OS (30GB virtual hard disk and 1GB memory): • Windows XP SP2 32-bit • Ubuntu Linux 12.04 32-bit A Seminar at Advanced Defense Lab

  20. Transparency A Seminar at Advanced Defense Lab • “Fail”means the program fails to run properly in the environment even without any trap. • “Fail HBP” and “Fail SBP”means the program fails to run properly after setting hardware breakpoint or software breakpoint.

  21. Case Study I: Spider + BEEP A Seminar at Advanced Defense Lab

  22. Performance Overhead A Seminar at Advanced Defense Lab

  23. Q & A A Seminar at Advanced Defense Lab