1. 1 SoK: Introspections on Trust and the Semantic Gap Bhushan Jain, Mirza Basim Baig, Dongli Zhang, Donald Porter, Radu Sion Operating Systems, Security, Concurrency and Architecture Research

2. 2  VMI is building block for layered security  Trusted hypervisor monitors less trusted guest  Common VMI goal: Identify processes in guest  Rootkit goal: Confuse VMI & hide malicious process  This paper/talk:  Organize prior VMI work by principal design choices  Pervasive trust assumptions in VMI systems  Search other related problems for ideas to remove trust VMI: Rootkit Detection Technique Guest OS Hyper visor

3. 3 VMI Challenge : Bridge the semantic gap even for compromised guest Guest OS Guest Kernel Heap Semantic Gap: A challenge for VMI Hypervisor VMI 10111001 11010100 10011100 10101011 01010011 11110010 11010110 01101010 Guest Kernel Heap Compromised Guest OS 01010011 11110010 11010110 01101010 10111001 11010100 10011100 10101011 Guest Kernel Heap VMI Challenge : Bridge the semantic gap Process Descriptors VMI

4. 4  Survey 12 years of VMI research ; 100 papers  Present a framework to reason about design choices  Contradiction: VMI reintroduces some trust in guest  Assume benign, initially uncompromised guest OS  Promising avenues to remove trust assumptions  Force guest OS to aid in its own introspection  Continuous adversarial learning on untrusted guest OS  Fine grained hardware support for memory protection Main Takeaways ~

5. 5  One VMI technique: Learning and Reconstruction  An example attack: Structure Manipulation  More VMI assumptions about attacker  Assumptions across all VMI design techniques Assumptions in VMI Techniques Ubiquitous trust assumptions across all VMI designs

6. 6 Learning and Reconstruction Hypervisor Linux Guest OS Guest Kernel Heap Learning Phase: Generate data structure signature 01010011 11110010 11010110 01101010 10111001 11010100 10011100 10101011 Guest Kernel Heap Searching Phase: Find data structure instances Assumption: Same OS behavior in learning and monitoring Offline safe environment Continuous over guest lifespan

7. 7 Hypervisor = Firefox = Chrome Linux Guest OS struct task_struct{ …… char comm[16]; void *notifier; …… } Data Structure Manipulation Attack Guest Kernel Heap 01010011 11110010 11010110 01101010 10111001 11010100 10011100 10101011 Guest Kernel Heap = Skype Typecast & offset math Process Command 1128 Offset = Adore-ng= Chrome Guest Kernel Heap Malicious or Compromised OS can violate VMI assumptions All processes are benign Initialization = Chrome Malicious Guest OS strlcpy(tsk->comm,”Chrome”,16); notifier = kmalloc(16,GFP_KERNEL); strlcpy(tsk->notifier, buf, 16); strlcpy(tsk->comm, buf, 16); Change field interpretation

8. 8  Assumption: Consistent structure interpretation  Attack: Change interpretation of a data structure  Mislead VMI tools by presenting false system state  Defense: No existing defense  CFI on benign kernel may help prevent bootstrapping  Attack obviated by generous threat models  Trust guest OS to be uncompromised and benign Fragile Trust Assumptions Structure manipulation: Realistic but outside threat model

9. 9 More Assumptions About Attacker Hypervisor Linux Guest OS Guest Kernel Heap 01010011 11110010 11010110 01101010 10111001 11010100 10011100 10101011 Guest Kernel Heap Assume attacker can’t win race with asynchronous checking Process tree used by scheduler Process list used to enumerate Invariant: Set of processes in Scheduler tree = Process list Invariant Violated!!!

10. 10  Write text Segment  Kernel Object Hooking (KOH)  Change function pointers (data segment)  Direct Kernel Object Manipulation (DKOM)  Manipulate heap objects – violate invariants  Dynamic Kernel Structure Manipulation (DKSM)  Change data structure interpretation Other Attack Techniques

11. 11 Trusted Guest Pervasive in VMI Current VMI techniques built on some level of trust in guest TechniqueApproachTrust Guest That Learn & Reconstruct Learn template then search  Same OS behavior in learning and monitoring phases Code Implanting Monitoring inside guest OS  Guest OS reports correct information Data Outgrafting Use sibling VM; share memory  Identical guest OS behavior in monitored and trusted sibling VM

12. 12 ChallengeApp Guest OS Hyper visor Semantic GapUTT ChallengeApp Guest OS Hyper visor Semantic Gap UTT UUT ChallengeApp Guest OS Hyper visor Weak Semantic GapUTT Strong Semantic GapUUT ChallengeApp Guest OS Hyper visor Weak Semantic GapUTT Strong Semantic GapUUT Untrusted Guest OSTUT Untrusted Cloud Hypervisor TTU Untrusted Guest OS and Hypervisor TUU A Fresh Look at Semantic Gap Any Insights? VMI Problems T U Trusted Untrusted Search related problems for techniques to remove trust

13. 13  Untrusted OS: Trusted app bridges semantic gap  Guest gives hypervisor evidence of correct behavior  Not directly applicable to problems solved by VMI  VMI tools implicitly assume unmodified guest OS  Relaxes threat model and induces trust  Can we force guest OS to help introspection?  Relax the constraint of unmodified OS Force Guest OS to Aid Introspection Make light modifications to guest OS to prove correctness

14. 14  VMI assumes same training & classification behavior  Least fundamental assumption  Apply continuous, adversarial machine learning  Incrementally train the VMI classifiers on untrusted OS  Detect inconsistent control flow, data access pattern Continuously Train on Untrusted OS Adapt adversarial learning for continuous VMI training

15. 15  Only detection of kernel invariant violation attacks  Asynchronous scanning to check violations  All prevention systems use memory protection  Expensive at page granularity  Map invariant detection to memory protection  Need lightweight fine-grained memory protection Fine-grained Hardware Support Fine-grained protection hardware can reduce trust assumption

16. 16  Semantic gap problem for benign OS is solved  Difficult open VMI problem for malicious OS  Adapt techniques from other trust models  Force guest OS to aid in its own introspection  Continuous adversarial learning on untrusted guest OS  Fine grained hardware support for memory protection Conclusions bpjain@cs.stonybrook.edu

17. 17 Backup

18. 18 Code Implanting Hypervisor Linux Guest OS Guest Kernel Heap struct task_struct *task; for_each_process(task) call_home("%s\n",task->comm); return 0; Protect the injected code Assumption: Guest OS reports correct information 10111001 11010100 10011100 10101011 01010011 11110010 11010110 01101010 Guest Kernel Heap Inject code in guest OS

19. 19 Data Outgrafting Hypervisor Trusted Sibling Guest OS Linux Guest OS Guest Kernel Heap COWCOW 10111001 11010100 10011100 10101011 01010011 11110010 11010110 01101010 Guest Kernel Heap Assumption: Identical guest OS behavior in both VMs 10111001 11010100 10011100 10101011 01010011 11110010 11010110 01101010 Guest Kernel Heap Reuse static trusted kernel code Input runtime heap & data