Monitoring Hypervisor Integrity at Runtime. Student: Cuong Pham PIs: Prof. Zbigniew Kalbarczyk, Prof. Ravi K. Iyer ACC Meeting, Oct 2015

Size: px

Start display at page:

Download "Monitoring Hypervisor Integrity at Runtime. Student: Cuong Pham PIs: Prof. Zbigniew Kalbarczyk, Prof. Ravi K. Iyer ACC Meeting, Oct 2015"

Ezra Russell
5 years ago
Views:

1 Monitoring Hypervisor Integrity at Runtime Student: Cuong Pham PIs: Prof. Zbigniew Kalbarczyk, Prof. Ravi K. Iyer ACC Meeting, Oct 2015

Motivation - Server Virtualization Trend x86 servers were

reports Virtual Machine App Virtual Machine App Virtual Machine

Derivative analysis based on Worldwide Virtual Machine 2013

2 Motivation - Server Virtualization Trend x86 servers were virtualized in 2012 Source: 451 Research's TheInfoPro service reports Virtual Machine App Virtual Machine App Virtual Machine App OS OS OS Hypervisor x86 Architecture Server 2 Source: Derivative analysis based on Worldwide Virtual Machine Forecast: Virtualization Buildout Continues Strong IDC # / Aug 2013

3 Building Secure & Reliable VMs Attack Surface Layer VM VM VM Hprobes (EDCC 15) HyperTap (DSN 14) OS/Hypervisor Firmware/Bios Hardware Load-time Execution Time 3 Chain of trust must be built from bottom up and continuously through time

4 Building Secure & Reliable VMs Attack Surface Layer VM VM VM HProbes (EDCC 15) HyperTap (DSN 14) OS/Hypervisor Intel TXT Firmware/Bios Hardware TPM Physical security Load-time Execution Time 4 Chain of trust must be built from bottom up and continuously through time

5 Protect Hypervisors: Existing approaches Attack Surface VM VM VM OS/Hypervisor Layer Intel TXT HyperSentry/SICE Periodically measure hypervisor integrity Vulnerable to transient attacks Firmware/Bios Hardware TPM Physical security Load-time Did I say continuously through time? Execution Time 5

6 Introducing hshield Attack Surface VM VM VM Layer HProbes HyperTap Continuously measure hypervisor integrity OS/Hypervisor Intel TXT hshield Firmware/Bios Hardware TPM Physical security 6 Assumption: Hardware is trusted TPM, Intel TXT are enabled Physical security Load-time Execution Time

7 Threat Model: VM Escape Attacks Virtual Machine Hypervisor Attack entry point Privileged Operation VM-exit VM-entry Hypervisor execution (handle VM-exit) Attack code 7 Hardware Assisted Virtualization Attackers have full control of guest OS Violate hypervisor Control Flow Integrity (CFI)

Example: Venom VM Attack (CVE-2015-3456) Virtual Machine KVM/XEN QEMU (version containsvenom vulnerability) fdctrl->fifo[fdctrl->data_pos++] = value; io(port 0x35, command 0x8e) VM Exit VM Entry

8 Example: Venom VM Attack (CVE ) Virtual Machine KVM/XEN QEMU (version containsvenom vulnerability) fdctrl->fifo[fdctrl->data_pos++] = value; io(port 0x35, command 0x8e) VM Exit VM Entry ioctl() overwrite QEMUBHFunc *bh->cb point to callq bh->cb Attack code 8 Description Though the VENOM vulnerability is also agnostic of the guest operating system, an attacker (or an attacker s malware) would need to have administrative or root privileges in the guest operating system in order to exploit VENOM Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service Source:

9 Threat Model: VM Escape Attacks Virtual Machine Hypervisor Attack entry point Privileged Operation VM Exit VM Entry Hypervisor execution (handle VM Exit) Attack code 9 Attack code DoS host Access other co-located VMs (e.g., sniffing network traffic, stealing images) Install backdoors, access secrets in host

10 VM Escape-enabling CVEs CVE Directory traversal vulnerability in shared folders feature CVE Path traversal vulnerability in VMware s shared folders implementation CVE Cloudburst (VMware virtual video adapter vulnerability) CVE bit PV guest privilege escalation vulnerability CVE Oracle VirtualBox 3D acceleration multiple memory corruption vulnerabilities CVE-2015-( ) Escaping VMware Workstation through COM1 (5 CVE!!!) CVE QEMU heap overflow flaw in floppy disk driver CVE QEMU heap overflow flaw while processing certain ATAPI commands. 10

11 hshield Design Goals 1. Resistance to zero-day VM escape attacks 2. Detect both transient and persistent attacks 3. Small performance overhead in attack-free executions 4. Support target randomization 11

12 hshield Approach Hardware OS/Hypervisor hshield TPM Continuous monitoring Detect both persistent and transient attacks White-list monitoring Detect unknown attacks Hardware extension Hardware isolation and performance 12

(handle VM-Exit) Stop measurement session H i Whitelist Check Match hshield Auditor No

13 hshield Overview Virtual Machine Hypervisor Start measurement session hshield Counter Execution trace i 1 i 2 i 2 i m Privileged Operation VM-exit VM-entry Hypervisor execution (handle VM-Exit) Stop measurement session H i Whitelist Check Match hshield Auditor No match 13 Detect a VM-escape attack right at the end of the exploited VM-exit: defeat transient attacks.

14 White-list vs. Black-list White-list No one can access except the white-listed Prevents unknown attacks E.g., Control Flow Integrity (CFI) techniques X Control Flow Graph (CFG) Black-list Everyone can access except the black-listed Prevents known (black-listed) attacks E.g., Signature-based malware detection 6 14 Signature based detection

15 Current CFI Techniques Heavily relies on static analysis to construct CFG No interactions with dynamic libraries, OS Heuristic (e.g., pointer analysis is imperfect) Scalability issues (e.g., large binaries) High runtime overhead Check at every branch Compatibility issues against Address Space Layout Randomization (ASLR) Programs relying on dynamic binary re-writing (e.g., Linux kernels) X Control Flow Graph (CFG) 15

16 hshield Approach Dynamic analysis to construct CFG Full system coverage Load-time binary rewriting compatible Check at the sink of executions Reduce runtime overhead Use hashes of basic blocks instead of addresses ASLR compatible Check = Source (VM-exit) Sink (VM-entry) 16

17 Workloads VM Hypervisor Most popular paths HotTable H 1 H 2 H t hshield Approach Find H i in HotTable No Yes Hash H i VM-exit CFG Construction Recomputed H i in CFG No Yes 5 6 VM-entry 5 Bad Good 17 Profiling 6 Runtime checking

18 Profiling Result: Path Popularity Setup: Qemu (HW) Qemu (Host) Linux VM (Guest) Workloads: Boot Linux kernel + UnixBench High hit rate of HotTable 1% paths 97% of exits 0.1% paths 95% of exits 18

19 Increase HotTable Hit Rate Execution Pattern Inference: Hash = a pattern of similar executions Noise reduction (e.g., exclude interrupt handlers) Loop rerolling Execution trace i 1 i 2 i 2 i m Pattern of executions bb 1 bb 2 bb n H i Noise reduction Loop rerolling Hash 19

20 Loop Rerolling Example a = 0; for (i = 1..n) a = 0 i = 1 Basic block 1 (BB1) a = a + i; return a; i <= n N BB2 BB1 BB2 BB4 BB1 BB2 BB3 BB4 BB1 BB2 BB3 BB2 BB3 BB4 Paths = 1 + Range(n) Y a = a + i i = i + 1 return a BB3 BB4 20

21 Loop Rerolling Example a = 0; for (i = 0..n) a = 0 i = 1 Basic block 1 (BB1) a = a + i; return a; i <= n N BB2 BB1 BB2 BB4 BB1 BB2 BB3 BB4 BB1 BB2 BB3 BB2 BB3 BB4 Paths = 2 Y a = a + i i = i + 1 return a BB3 BB4 21 Solution: Loop rerolling

22 Workloads VM Hypervisor Most popular paths CFG Construction Small size Fast Lookup High hit rate (>95%) 3 HotTable H 1 H 2 H t hshield Approach Find H i in HotTable Bad No Recomputed H i in CFG No Yes Yes Hash H i Good VM-exit VM-entry 22 Profiling 6 Runtime checking

23 Workloads VM Hypervisor Most popular paths CFG Construction hshield Approach 3 HotTable 1 2 H 1 H 2 How to efficiently verify H i is recomputable in the CFG? H t 4 Find H i in HotTable No Recomputed H i in CFG No Yes Yes Hash H i VM-exit VM-entry 5 Bad Good 23 Profiling 6 Runtime checking

24 Execution Path Reconstruction Input Hash H i and CFG G=<V, E> Question: Exist a path P G: Hash(P) = H i Naïve solution: Traverse G until P is found - impractical hshield Solution: Using incremental hashing to efficiently reconstruct P from H i and G 24

25 Execution Path Reconstruction Source Is 1 first basic block? Yes, update( 1, H i ) == H i Is 2 first basic block? Yes, update( 2, H i ) == H i Is 3 first basic block? No, update( 3, H i )!= H i Hash H i Sink Is 4 first basic block? Yes, update( 4, H i ) == H i 6. end at 6 25

26 Execution Representation f: Exe Range E Exe: E = I 1 I 2..I n I i : Instruction byte code (e.g., x86) Range: Fixed length output f requirements Collision resistant Interactive online construction Incremental online update Facilitate loop rerolling implementation 26

27 Incremental Collision-free Hashing [1] Randomization Combination Message E h(<1>b 1 ) h(<2>b 2 ) h(<n>b n ) f(e) Randomization Derived from standard cryptographic functions (e.g., SHA, MD5) Combination Algebraic operation Incrementality: Allow update results when a portion of input changed without re-computing from scratch Collision-free [1] [1] M. Bellare and D. Micciancio, A new paradigm for collision-free hashing: Incrementality at reduced cost, in 27 Advances in Cryptology EU- ROCRYPT97. Springer, 1997, pp

28 hshield Counter Hash Function Execution E B 1 =<1>.s.B 1 B 2 =<2>.s.B 2 B n =<n>.s.b n y 2 = sha1(salt.<2>.b2) B 2 MuHASH(y1, y2) = y1 y2 [address: instruction]

29 hshield Counter Hash Function Execution E B 1 =<1>.s.B 1 B 2 =<2>.s.B 2 B n =<n>.s.b n sha1(b 1 ) sha1(b 2 ) sha1(b n ) B = Basic block facilitate loop rerolling s: salt individualize target : modular multiplication (MuHash) 29 f(e) F(E) = i=1..n (sha1(<i>.s.b i ))

30 Security Evaluation E h salt F(E) Know Change 30 Attack Model Change execution E > E : f(e ) F(E) Solution Find E complexity = Discrete Log problem (assuming h is ideal) Must harder to find an E which is valid x86 code

31 Scopes 31 Focus on design of the monitoring framework What/Where/How to monitor (Answers: VM Exit/Hardware/Whitelist) Design for flexible future hardware implementation Make best effort to conduct measurement on actual hardware E.g., obtained supporting data on physical systems. Make best effort to anticipate problems in actual hardware implementation. E.g., issues with speculative execution, memory size constraints. Assume that we can place hooks in some basic signals in the hardware. E.g., intercept all interrupts and exceptions. Prototype the proposal in QEMU Software emulation of x86 processors and many external devices.

32 Archirectural Design Evaluation with real attacks Performance evaluation More to come 32

Resilience of Cyber-Physical Systems and Technologies

Resilience of Cyber-Physical Systems and Technologies Zbigniew Kalbarczyk and Ravishankar K. Iyer University of Illinois at Urbana-Champaign Email: {kalbarcz, rkiyer}@illinois.edu Depend Research Group