Author : Jiang Wang, Angelos Stavrou, and Anup Ghosh Conference: RAID 2010 Advisor: Yuh-Jye Lee Reporter: Yi-Hsiang Yang /4/28

Outline Introduction Related Work System Architecture Implementation Evaluation Conclusion /4/28

Introduction Virtual Machine Monitors (VMMs) Deep isolation of untrusted software components Attackers towards VMM vulnerabilities HyperCheck Works at the BIOS level CPU System Management Mode (SMM) /4/28

Related work Copilot employed a special PCI device to poll the physical memory of the host and send it to an admin station periodically HyperGuard Rutkowska et al. suggested using SMM of the x86 CPU to monitor the integrity of the hypervisors DeepWatch also offers detection of hypervisor rootkits by using the embedded micro-controller(s) in the chipset. Relying on hardware-assisted virtualization technologies such as Intel VT-d Flicker uses a TPM based method to provide a minimum Trusted Code Base (TCB), which can be used to detect the modification to the kernels 42011/4/28

Threat model System Management Mode (SMM) Intel386 SL and Intel486 SL processors The processor enters SMM when the external SMM interrupt pin (SMI#) is activated or received from the advanced programmable interrupt controller (APIC) Processor switches to a separate address space, called system management RAM (SMRAM) 52011/4/28

Attacker’s capabilities Exploit vulnerabilities in any software after bootup. Eg. compromise a guest domain and escape to the privileged domain Modify the hypervisor code or data using any known or zero-day attacks. Eg. DMA attack 62011/4/28

General Assumptions Attacker cannot tamper with PCI NIC using the same driver interface SMRAM is properly setup by BIOS upon boot time and locked Limitations Analysis cannot protect against attacks that modify the dynamically generated function pointers 72011/4/28

In-scope Attacks Aims to detect the in-memory Ring-0 level rootkits Rookits A set of programs and code that allows a permanent or consistent Modifies the memory and/or registers Runs in the kernel level Eg. idt-hook rootkit Modifies the interrupt descriptor table (IDT) Gains the control of the complete system 2011/4/288

System Architecture HyperCheck is composed of three key components Physical memory acquiring module Reads the contents of the physical memory Sends data to the analysis module Analysis module Checks the memory contents and verifies if anything is altered CPU register checking module Reads the registers and validates 92011/4/28

System Architecture /4/28

System Architecture HyperCheck should not rely on any software running Use hardware PCI Ethernet card– as memory acquiring module SMM to read the CPU registers Uses the CR3 register Translate the virtual addresses to the physical addresses /4/28

System Architecture -Acquiring the physical memory Two ways to acquire the physical memory Software method /dev/kmem on Linux or \Device\PhysicalMemory on Windows If the operating system or the hypervisor is compromised Hardware method Uses a PCI device Depends less on the integrity of the operating system or the hypervisor /4/28

System Architecture -Acquiring the physical memory HyperCheck puts drivers into the SMM code To prevent from a malicious NIC driver in the OS to spoof the SMM driver Use a secret key obtained from the monitor machine when booting up and stored in the SMRAM Denial of service(DoS) attacks Advanced Configuration and Power Interface (ACPI) Allow the operating system to control the state of the devices /4/28

System Architecture -Translating the physical memory Three properties of the kernel memory Linear mapping Kernel memory is linearly mapped to physical memory Static nature Contents of monitoring part of hypervisor have to be static Persistence Memory will not swap to the hard disk /4/28

System Architecture - Reading and verifying the CPU registers Ethernet card cannot read the CPU registers Use SMM in x86 CPU When switches to SMM it saves the register context in the SMRAM Focuses on monitoring two registers: IDTR Should never change after system initialization CR3 Translate the physical addresses of the hypervisor kernel code and data /4/28

Implementation HyperCheck-I Virtual machine uses QEMU Analysis module runs on the host of QEMU Placed NIC driver into the SMM Program runs in the SMM and collects and sends out the CPU registers via the Ethernet card Quick Prototyping and Debugging QEMU network card is much lower than a real NIC device (10MB/s) Performance may not reflect the real world performance /4/28

Implementation -Memory Acquiring module SMM code is one part of BIOS Using SMM for ”Other Purposes”. Phrack Magazine, 2008 Writes the SMM code in 16bit assembly Uses a user level program to open the SMRAM Copy the assembly code to the SMRAM Program the transferring part in assembly Assembly code is compiled to an ELF object file Write a loader parse the ELF object file and load the code and data to the SMM Modified the existing Linux E1000 driver to initialize the network card /4/28

Implementation -Memory Acquiring module Two transmission descriptors per packet Header NIC is already initialized by OS Data Prepare Descriptor table and write it to the Transmit Descriptor Tail (TDT) register of the NIC Secret key Create a random seed to selectively hash the data for one-time pad encryption Serial random numbers indexes of the positions of the memory being scanned /4/28

Implementation -Analysis module CentOS 5.3 Tcpdump to filter the packets from the acquiring module and output is sent to the analysis module Recovers the contents using the same secret key Written in a Perl script reads the input and checks for any anomalies Compares every two consecutive memory snapshots Check the integrity of the control data and code Control data includes IDT table, hypercall table and exception table of Xen /4/28

Implementation -CPU register checking module Triggering SMI to enter SMM SMI is often used for power management, and Southbridge provides some timers to monitor the state of a device Employ the Ethernet card to trigger the SMI event Checking the registers in SMM Reporting the result /4/28

Implementation HyperCheck-II Target Xen 3.1 Intel E1000 Ethernet card SMM NIC driver from the QEMU VM does not work on the physical machine NIC can access the SMRAM in a QEMU VM Reserved 12MB for HyperCheck by using mem parameter Monitor Analysis module Used for performance measurement /4/28

Evaluation HyperCheck-I Dell Precision 690 8GB RAM 3.0GHz Intel Xeon CPU with two cores The host : CentOS bit QEMU version was Xen version was Domain 0 was CentOS bit with PAE HyperCheck-II Dell Optiplex GX GHz Intel Pentium 4 CPU 512MB memory Xen 3.1 and Linux Domain 0 is CentOS /4/28

Evaluation -Detection HDD DMA attacks to modify the Xen hypervisor and Domain 0 Four attacks to Xen hypervisor and Two attacks to Domain 0 Modified pcnet NIC in QEMU to attack Linux and Windows operating systems /4/28

Evaluation -Monitoring overhead 24 Internal NIC transfer FIFO is 16KB 2011/4/28

Evaluation -Operation Two programs Use Dummy SMM code Time for switching between protected mode & SMM Use the registers to simulate the verification of IDTR and CR3 Sending the data : 73 Million cycles. Accessing the main memory : 5.28 Million cycles. The total time is 80 Million cycles /4/28

Evaluation - Overhead of the operations /4/28

Evaluation Reading memory contents and comparing Total 230 ms 49 ms for only comparing the data /4/28

Evaluation /4/28

Conclusion Introduced HyperCheck-a hardware-assisted tamper detection framework Rely on CPU System Managed Mode (SMM) Implemented two prototypes : QEMU and physical x86 machine HyperCheck operation is relatively lightweight Produce and communicate a scan of the state of the protected software in less than 40ms /4/28

Thanks for listening! Q&A 2011/4/2830