Jiang Wang , Joint work with Angelos Stavrou and Anup Ghosh CSIS, George Mason University

1. HyperCheck: a Hardware Assisted Integrity Monitor Jiang Wang, Joint work with Angelos Stavrou and Anup Ghosh CSIS, George Mason University

2. Outline • Motivation • Our approach • Prototype Implementation • Evaluation • Future work

3. Motivation • Virtualization is widely deployed for servers and desktops. • In 2009, 18% server workloads were virtualized • Expected to grow to more than 50% by 2012 (Gartner Inc.) • Hypervisors (also called Virtual Machine Monitors or VMM) are the core component to enforce policy. • Hypervisors are the new attack target. Privileged Domain Guest OS 2 (Linux) Guest OS 1 (Windows) … Kernel 2 Kernel 1 Kernel 0 Hypervisor (Virtual Machine Monitor) Hardware

4. VMMs vulnerabilities and attacks • Xen vulnerabilities: • Allow the attacker to run arbitrary code in the privileged domain. E.g. CVE-2007-4993, CVE-2007-1320, • DMA attack (Invisible Things Lab, Blackhat 08) • Modify the device driver to write arbitrary data to the hypervisor via DMA • E.g. Interrupt Descriptor Table (IDT). HyperCall table.

5. IDT hook • Modify IDT directly 1 2 3 . . . Org IDT Code in memory

6. IDT hook • Copy and change attack 1 1 2 2 3 3 . . . . . . Org IDT New IDT Code in memory

7. Out-of-VMM defense mechanisms • Copilot (Petroni et al. USENIX security ‘04 ). • Cannot get execution state. Copy and change attack. • Can be subverted by DMA remapping attack. • HyperGuard (Rutkowska, Blackhat ‘08). • Use SMM to get the execution state. • The OS is frozen when CPU in SMM –- high overhead. • HyperSentry, (Azab et al. CCS’ 10) • Use SMM to monitor the hypervisor integrity. • DeepWatch (Bulygin, Blackhat ‘08). • Based on micro-controller existed on some motherboard. • Need the signature of the malware.

8. In-VMM defense mechanisms • HyperSafe, (Wang, Oakland ’10) • Method: non-modifiable memory lockdown and restricted pointer indexing • Drawbacks: need to modify the kernel; aliasing problem

9. Our approach: HyperCheck • Design goals: • To monitor the hypervisor code and static data • Complete execution view • Low performance overhead • No hardware modification • No software changes to the hypervisor or kernel • Provide out-of-box view that cannot be subverted

10. HyperCheck architecture • SMM + COTS network card (NIC) • SMM existed in all x86 CPU after 486. (1) Acquiring module (2) Register Checking module

11. SMM Background • System Management Mode (SMM) is another CPU mode for x86 • To enter SMM, a System Management Interrupt (SMI) is required. • SMM has a special RAM—SMRAM, and can be LOCKED. • SMM code is included in the BIOS. Real-address mode SMRAM Protected mode SMM

12. Assumptions & threat model • SMRAM cannot be modified: • Locked by hardware in flash and memory • Can be integrated with BIOS code • Can be set up by a trusted boot module • Other software on the target machine is not trusted. • Network card driver is put into SMM. • The attacker will modify some portion of the hypervisor kernel in the memory.

13. Logic steps of HyperCheck PCI NIC triggers SMI SMM check the CPU registers SMM send the memory out via NIC Analysis module rcv the data YES Different from the previous? Alarm

14. Implementation • Two prototypes: • HyperCheck-I : QEMU based, easy debugging • HyperCheck-II: on real hardware. For performance evaluation. • Protect static part of the VMM or OS • VMM code • Dom 0 code • Linux or Windows kernel code • Static control data (such as Interrupt Descriptor Table)

15. Memory acquiring module • PCI devices with DMA support • Use commercial network cards • Challenge: they need drivers, and drivers normally reside in untrusted OS, Driver Domain, or VMM. • Solution: put the driver into SMM. • We used Intel e1000 NIC.

16. Register checking module • Resides in SMM • Previous CPU registers are saved in SMRAM before switching to SMM. • Check two registers: • IDTR (Interrupt Descriptor Table Register): static • CR3: page directory base register. Used to translate virtual addresses to physical ones.

17. Analysis module • Receive the packets from the acquiring module. • Compare the current memory snapshot with the clean state (obtained when the system just boot). • If different, potential attack.

18. Evaluation • Verifying the static property: • Monitored the target code and data for one hour and didn’t find any changes. • They do change when the system is booting • Detection • Detected all the simulated attacks to the Xen hypervisor, Dom0, Linux and Windows kernels.

19. Summary of the static properties and detection test

20. Network Overhead (1) Network overhead for variable packet size when sending 2.7MB data.

21. Network Overhead (2) Network overhead for variable data size.

22. SMM operation overhead

23. Comparing with other methods Table 1, CPU overhead comparison Table 2, features comparison

24. Limitations & Future work • Scrubbing attack • Modify the hypervisor between two scans interval and recover before the next scan. • -- Randomize scan interval. • Dynamic data • Current analysis module does not know how to check them, such as stack, heap. • -- Syntax analysis.

25. Thank you! Questions?