Transcript Detecting past and present intrusions through vulnerability

Detecting past and present
intrusions through vulnerabilityspecific predicates
Ashlesha Joshi, Sam King,
George Dunlap, and Peter Chen
Index
•
•
•
•
•
•
•
Authors
Motivation & Introduction
Goals
Challenges & Solutions
Evaluation
Related work
Conclusion
2
Author group
• EECS Department
University of Michigan
• Peter M. Chen is the leader of the group, and
the other 3 authors are his students.
• The group is investigating how to add security
services through virtual machines.
• Paper: Operating System Support for Virtual
Machines
USENIX 2003
3
Authors
 Ashlesha Joshi
Ph.D in Computer Science,
University of Michigan
4
 Samuel T. King
2006 Ph.D University of Michigan
Now in University of Illinois at Urbanna-Champain
Research areas: Operating System, Security and VM.
important papers:
1.Virtualization and Security: Back to the Future IEEE
S&P 2008
2.SubVirt: Implementing malware with virtual machines
IEEE S&P2006
3.Capo: a software-hardware interface for practical
deterministic multiprocessor replay
ASPLOS '09
5
 George Washington Dunlap
Ph.D University of Michigan
Research areas: Operating System , VM.
important papers:
1.Execution replay of multiprocessor virtual
machines
VEE’08
2.Debugging operating systems with timetraveling virtual machines
ATEC '05
6
 Peter M. Chen
1992,Ph.D. in Computer Science from the University of California
at Berkeley ,
Research areas:
Operating Systems, Databases, Distributed Systems.
important papers:
1. Tolerating latency in replicated state machines through client
speculation
NSDI’09
2. Execution replay of multiprocessor virtual machines
VEE,08
3. Rethink the sync
OSDI’06
4. Backtracking intrusions
SOSP’03
7
Motivation
vulnerability
introduced
Vulnerability
discovered
patch
released
patch
applied
time
• Software contains bugs, including flaws that may
be exploited by an attacker
• Some time passes before vendor becomes
aware of bug
• Software vendors try to release patches quickly
8
Motivation
vulnerability
introduced
Vulnerability
discovered
patch
released
patch
applied
time
• Was this vulnerability triggered on my machine
in the past?
• Can I somehow protect my system before I
install the patch?
9
Predicates
• Patch writer knows exactly what conditions
during program execution indicate
triggering of vulnerability
• Use this knowledge to write vulnerabilityspecific predicates that check these
conditions
– No false positives or false negatives
10
An example
1
char *str = some_string;
2
int
length = strlen (str);
3
char buf [BUFSIZE];
4
strcpy(buf,str);
// D’oh!
Predicate:
(length >= BUFSIZE)
11
Approach
“past”
vulnerability
introduced
Using replay, detect
if vulnerability was
triggered in past
“present”
patch
released
patch
applied
time
Monitor ongoing execution to
detect and respond to attempts
to trigger vulnerability
12
Goals
The system must…
1. Not perturb the target software
2. Work for both OS and application-level
vulnerabilities
3. Allow predicates to be installed dynamically
4. Allow predicates to be written easily
5. Have low overhead
13
Challenge #1: Where do predicates
execute?
On a normal computer, software runs either as a
user-level application or in the operating system
kernel. Neither of these locations is suitable for
executing predicates because predicates should
run outside the target system to avoid perturbing
its state.
14
IntroVirt structure
predicates
application
application
guest OS
state
control
predicate
engine
intrusions
detected
VMM
host OS
hardware
15
Challenge #2: Semantic gap
Problem: VMM exposes guest state at the wrong
level of abstraction
– It gives us registers, memory locations, disk blocks, …
– We want program variables, files, …
1
2
3
uid = getuid();
// forget to check group membership
perform privileged action
Predicate
– Perform missing authentication, e.g., read /etc/group
16
Bridging the semantic gap
• How could the programmer write this predicate?
– Determine memory location where uid is stored; if
page not resident, read from disk; read value of uid;
traverse guest OS file system structures to see if
/etc/group in file cache, if so, read from memory; if not,
traverse FS structures to see which disk blocks
contain it, then read blocks from disk; …
– i.e., emulate guest functionality
• Our solution: call guest code
– Leverages existing guest code that does what we
want
– Here, we cause the guest itself to read the file and
check group membership
17
Challenge #3: Avoiding
perturbations to target state
• Calling guest functions perturbs target
• Solution: use checkpoint and restore
– Take a checkpoint before changing guest
state
– Restore to checkpoint after predicate
execution
• Also protects from (buggy) predicates that
modify guest state incorrectly
18
Challenge #4: Preemptions
between the predicate and the bug
• the state checked by the predicate can
change after the predicate executes but
before the state is used by the vulnerable
code.
19
Predicate refresh
• Detect and respond to race
– “Predicate refresh”
– Observation: in uniprocessors, a scheduling
event must occur before any other process
can run
– Re-execute predicate on scheduling events to
detect relevant changes in state
20
Evaluation
• The system has 5 goals. Goal 1,2,3 are
met by design.
• Goal 4:Allow predicates to be written easily and
goal 5:low overhead, are the main evaluation
objectives.
21
Example Predicates
• CAN-2003-096:
• This bug involves a missing bounds check
in the Linux kernel’s do_brk function
• The function neglects to check for integer
overflow and to check if the process is
trying to expand its heap above the
address TASK SIZE. The patch consists of
the following code, inserted before line
1044 of mmap.c
22
Predicate for CAN-2003-0961
Actual Patch:
if((addr + len) > TASK_SIZE || (addr + len) < addr)
return –EINVAL;
Predicate:
registerBreak(“mmap.c:1044:begin”, brkEventHandler);
void brkEventHandler() {
unsigned long addr = readVar(“addr”);
unsigned long len = readVar(“len”);
if((addr+len) > TASK_SIZE || (addr+len) < addr) {
cout << “brk bug triggered” << endl;
}
}
23
CAN-2002-0656
• Vulnerability:
static int get_client_master_key(SSL *s) {
...
s->session->key_arg_length=i; // line 419
s->state=SSL2_ST_GET_CLIENT_MASTER_KEY_B;
...}
• Patch:
if(i > SSL_MAX_KEY_ARG_LENGTH) {
SSLerr(SSL_F_GET_CLIENT_MASTER_KEY,
SSL_R_KEY_ARG_TOO_LONG);
return -1; }
24
• Predicate:
void sslEventHandler() {
unsigned long i = readVar("i");
if(i > SSL_MAX_KEY_ARG_LENGTH)
// "kill process" response strategy
introvirt.killCurrentProcess();
}
25
Experience
• Wrote predicates for 20 real vulnerabilities (Linux
kernel, bind, emacs, gv, imapd, OpenSSL, php,
smbd, squid, wu-ftpd, xpdf)
– Easy to write once vulnerability is understood
– Length and complexity comparable to patch
– Most are simple, e.g., just read a few variables
• Overhead for most predicates is less than 10%
– Many predicates are on infrequently executed code
paths
– Frequently executed predicates are simple and fast
– Checkpoint/restore adds 5ms
26
Predicates they have written
27
Related work
• VM introspection [Rosenblum97]
• VM introspection for intrusion detection
[Garfinkel03]
• Shield [Wang04]
• Vigilante [Costa05]
28
Conclusions
• Vulnerability-specific predicates detect
triggering of software vulnerabilities
• IntroVirt predicate engine
– Simple to write general-purpose predicates
– No perturbations in state
• Alert users about past attacks
• Detect and respond to attacks in the
present
29