SoK: Introspections on Trust and
the Semantic Gap
Bhushan Jain, Mirza Basim Baig, Dongli Zhang,
Donald Porter, Radu Sion, s&p14
Fall 2014
Presenter: Kun Sun, Ph.D.
Thank Bhushan and Radu for sharing the slides.
VMI: Rootkit Detection Technique

VMI is building block for layered security


Common VMI goal: Identify processes in guest


Trusted hypervisor monitors less trusted 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
Guest OS
Hyper
visor
Semantic Gap: A challenge for VMI
Compromised
Guest OS
Guest Kernel
Kernel Heap
Heap
Guest
Guest OS
Hypervisor
01010011
11110010
11010110
01101010
Process
VMI
Descriptors
10111001
11010100
10011100
10101011
Semantic Gap
VMI
Guest Kernel Heap
01010011
11110010
11010110
01101010
10111001
11010100
10011100
10101011
VMI Challenge : Bridge the semantic gap
even for compromised guest
Main Takeaways

Survey 12 years of VMI research ; 100 papers


Contradiction: VMI reintroduces some trust in
guest


Present a framework to reason about design choices
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
VMI Techniques

Learning and Reconstruction

Code Implanting

Data Outgrafting
Learning and Reconstruction
Guest Kernel Heap
Offline safe
environment
Linux Guest OS
Hypervisor
Guest Kernel Heap
01010011
11110010
11010110
01101010
Learning Phase: Generate
data structure signature
10111001
11010100
10011100
10101011
Continuous over
guest lifespan
Searching Phase: Find
data structure instances
Assumption: Same OS behavior in learning and monitoring
Code Implanting
Guest Kernel Heap
Linux Guest OS
Guest Kernel Heap
01010011
11110010
11010110
01101010
Inject code in
guest OS
Protect the
injected code
struct task_struct *task;
for_each_process(task)
call_home("%s\n",task->comm);
return 0;
Hypervisor
10111001
11010100
10011100
10101011
Assumption: Guest OS reports correct information
Data Outgrafting
Reuse static trusted
kernel code
Guest Kernel Heap
Guest
Kernel
Heap
10111001
01010011
11110010
11010110
01101010
11010100
10011100
10101011
Linux Guest OS
Trusted Sibling Guest OS
Hypervisor
Guest Kernel Heap
01010011
11110010
11010110
01101010
CO
W
Guest Kernel Heap
10111001
11010100
10011100
10101011
Input runtime
heap & data
Assumption: Identical guest OS behavior in both VMs
Assumptions in VMI Techniques




One VMI technique: Learning and
Reconstruction
An example attack: Structure Manipulation
More VMI assumptions about attacker
Assumptions across all VMI design techniques
Ubiquitous trust assumptions across all VMI designs
Data Structure Manipulation Attack
Malicious Guest OS
struct task_struct{
Guest
Guest
Kernel
Kernel
Heap
Heap
……
Offset Process Command
……
strlcpy(tsk->comm,”Chrome”,16);
strlcpy(tsk->comm,
buf, 16);
1128 char comm[16];
notifier = kmalloc(16,GFP_KERNEL);
void *notifier;
strlcpy(tsk->notifier, buf, 16);
……
Initialization
}
Change field
Linux Guest OS
interpretation
Hypervisor
Typecast & offset Guest Kernel Heap
10111001
01010011
Firefox
= Chrome
11010100
math
11110010
10011100
11010110
= Chrome
Skype
All processes
10101011
01101010
= Chrome
Adore-ng
are benign
Malicious or Compromised OS can violate VMI assumptions
Fragile Trust Assumptions



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
Structure manipulation: Realistic but outside threat model
More Assumptions About Attacker
Invariant: Set of processes in
Scheduler tree = Process list
Guest Kernel Heap
Guest Kernel Heap
Process list
used to
enumerate
Process tree
used by
scheduler
Invariant Violated!!!
Guest Kernel Heap
01010011
11110010
11010110
01101010
Linux
Guest
OS
Hypervisor
10111001
11010100
10011100
10101011
Assume attacker can’t win race with asynchronous checking
Other Attack Techniques


Write text Segment
Kernel Object Hooking (KOH)


Direct Kernel Object Manipulation (DKOM)


Change function pointers (data segment)
Manipulate heap objects – violate invariants
Dynamic Kernel Structure Manipulation
(DKSM)

Change data structure interpretation
A Fresh Look at Semantic Gap
Challenge
App
Guest
OS
T
T
U
Hyperv
isor
T
T
T
Weak Semantic Gap
Semantic Gap
Strong Semantic Gap
U
U
U
Untrusted Guest OS
T
U
T
Untrusted Cloud
Hypervisor
T
T
U
Untrusted Guest OS
and Hypervisor
T
U
U
T Trusted
U Untrusted
VMI
Problems
Any
Insights?
Search related problems for techniques to remove trust
Force Guest OS to Aid
Introspection

Untrusted OS: Trusted app bridges semantic
gap



VMI tools implicitly assume unmodified guest
OS


Guest gives hypervisor evidence of correct
behavior
Not directly applicable to problems solved by VMI
Relaxes threat model and induces trust
Can we force guest OS to help introspection?

Relax the constraint of unmodified OS
Make light modifications to guest OS to prove correctness
Continuously Train on Untrusted OS

VMI assumes same training & classification
behavior


Apply continuous, adversarial machine learning


Least fundamental assumption
Incrementally train the VMI classifiers on untrusted
OS
Detect inconsistent control flow, data access
pattern
Adapt adversarial learning for continuous VMI training
Fine-grained Hardware Support

Only detection of kernel invariant violation
attacks


All prevention systems use memory protection


Asynchronous scanning to check violations
Expensive at page granularity
Map invariant detection to memory protection

Need lightweight fine-grained memory protection
Fine-grained protection hardware can reduce trust assumption
Conclusions



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