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

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 TechniqueGuest OS

Hypervisor

3

VMI Challenge : Bridge the semantic gap even for compromised guest

Guest OS

Guest Kernel Heap

Semantic Gap: A challenge for VMI

Hypervisor

VMI10111001110101001001110010101011

01010011111100101101011001101010

Guest Kernel Heap

Compromised Guest OS

01010011111100101101011001101010

10111001110101001001110010101011

Guest Kernel HeapSemantic G

ap

VMI Challenge : Bridge the semantic gap

ProcessDescriptors

VMI

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

One VMI technique: Learning and ReconstructionAn example attack: Structure ManipulationMore VMI assumptions about attackerAssumptions across all VMI design techniques

Assumptions in VMI Techniques

Ubiquitous trust assumptions across all VMI designs

6

Learning and Reconstruction

Hypervisor

Linux Guest OS

Guest Kernel Heap

Learning Phase: Generate data structure signature

01010011111100101101011001101010

10111001110101001001110010101011

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

Hypervisor= Firefox= Chrome

Linux Guest OS

struct task_struct{ …… …… char comm[16]; void *notifier; ……}

Data Structure Manipulation Attack

Guest Kernel Heap

01010011111100101101011001101010

10111001110101001001110010101011

Guest Kernel Heap

= Skype

Typecast & offset math

Process Command1128

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

Assumption: Consistent structure interpretation Attack: Change interpretation of a data structure

Mislead VMI tools by presenting false system stateDefense: 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

More Assumptions About Attacker

Hypervisor

Linux Guest

OS

Guest Kernel Heap

01010011111100101101011001101010

10111001110101001001110010101011

Guest Kernel Heap

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 inScheduler tree = Process list

Invariant Violated!!!

10

Write text SegmentKernel Object Hooking (KOH)

Change function pointers (data segment)Direct Kernel Object Manipulation (DKOM)

Manipulate heap objects – violate invariantsDynamic Kernel Structure Manipulation (DKSM)

Change data structure interpretation

Other Attack Techniques

11

Trusted Guest Pervasive in VMI

Current VMI techniques built on some level of trust in guest

Technique Approach Trust Guest ThatLearn & 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

Challenge App Guest OS

Hypervisor

Semantic Gap U T T

Challenge App Guest OS

Hypervisor

Semantic GapU T TU U T

Challenge App Guest OS

Hypervisor

Weak Semantic Gap U T TStrong Semantic Gap U U T

Challenge App Guest OS

Hypervisor

Weak Semantic Gap U T TStrong Semantic Gap U U T

Untrusted Guest OS T U T

Untrusted Cloud Hypervisor T T U

Untrusted Guest OS and Hypervisor T U U

A Fresh Look at Semantic Gap

Any Insights?

VMI Problems

TU

TrustedUntrusted

Search related problems for techniques to remove trust

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

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

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

Semantic gap problem for benign OS is solvedDifficult open VMI problem for malicious OSAdapt 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

Backup

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

10111001110101001001110010101011

01010011111100101101011001101010

Guest Kernel Heap

Inject code in guest OS

19

Data Outgrafting

Hypervisor

Trusted Sibling Guest OSLinux Guest OS

Guest Kernel Heap COW

Guest Kernel Heap10111001110101001001110010101011

01010011111100101101011001101010

Guest Kernel Heap

Assumption: Identical guest OS behavior in both VMs

10111001110101001001110010101011

01010011111100101101011001101010

Guest Kernel Heap

Reuse static trusted kernel code

Input runtime heap & data