Detecting past and present intrusions through vulnerability specific predicates
This presentation is the property of its rightful owner.
Sponsored Links
1 / 29

Detecting past and present intrusions through vulnerability-specific predicates PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on
  • Presentation posted in: General

Detecting past and present intrusions through vulnerability-specific predicates. Ashlesha Joshi, Sam King, George Dunlap, and Peter Chen. Index. Authors Motivation & Introduction Goals Challenges & Solutions Evaluation Related work Conclusion. Author group.

Download Presentation

Detecting past and present intrusions through vulnerability-specific predicates

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Detecting past and present intrusions through vulnerability specific predicates

Detecting past and present intrusions through vulnerability-specific predicates

Ashlesha Joshi, Sam King,

George Dunlap, and Peter Chen


Index

Index

  • Authors

  • Motivation & Introduction

  • Goals

  • Challenges & Solutions

  • Evaluation

  • Related work

  • Conclusion


Author group

Author group

  • EECS DepartmentUniversity 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


Authors

Authors

  • Ashlesha Joshi

    Ph.D in Computer Science,

    University of Michigan


Detecting past and present intrusions through vulnerability specific predicates

  • 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:

  • Virtualization and Security: Back to the Future IEEE S&P 2008

  • SubVirt: Implementing malware with virtual machines IEEE S&P2006

  • Capo: a software-hardware interface for practical deterministic multiprocessor replay

    ASPLOS '09


Detecting past and present intrusions through vulnerability specific predicates

  • George Washington Dunlap

    Ph.D University of Michigan

    Research areas: Operating System , VM.

    important papers:

  • Execution replay of multiprocessor virtual machines VEE’08

  • Debugging operating systems with time-traveling virtual machines ATEC '05


Detecting past and present intrusions through vulnerability specific predicates

  • 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:

  • Tolerating latency in replicated state machines through client speculation NSDI’09

  • Execution replay of multiprocessor virtual machines VEE,08

  • Rethink the sync OSDI’06

  • Backtracking intrusions SOSP’03


Motivation

vulnerability introduced

patch released

Vulnerability discovered

patch applied

Motivation

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


Motivation1

vulnerability introduced

vulnerability introduced

patch released

patch released

Vulnerability discovered

patch applied

patch applied

Motivation

time

time

  • Was this vulnerability triggered on my machine in the past?

  • Can I somehow protect my system before I install the patch?


Predicates

Predicates

  • Patch writer knows exactly what conditions during program execution indicate triggering of vulnerability

  • Use this knowledge to write vulnerability-specific predicates that check these conditions

    • No false positives or false negatives


An example

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)


Approach

vulnerability introduced

patch released

patch applied

Approach

“past”

“present”

time

Using replay, detect if vulnerability was triggered in past

Monitor ongoing execution to detect and respond to attempts to trigger vulnerability


Goals

Goals

The system must…

  • Not perturb the target software

  • Work for both OS and application-level vulnerabilities

  • Allow predicates to be installed dynamically

  • Allow predicates to be written easily

  • Have low overhead


Challenge 1 where do predicates execute

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.


Introvirt structure

IntroVirt structure

predicates

application

application

state

predicate

engine

intrusionsdetected

guest OS

control

host OS

VMM

hardware


Challenge 2 semantic gap

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 uid = getuid();

    2// forget to check group membership

    3 perform privileged action

    Predicate

  • Perform missing authentication, e.g., read /etc/group


Bridging the semantic gap

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


Challenge 3 avoiding perturbations to target state

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


Challenge 4 preemptions between the predicate and the bug

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.


Predicate refresh

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


Evaluation

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.


Example predicates

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


Predicate for can 2003 0961

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;

}

}


Can 2002 0656

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; }


Detecting past and present intrusions through vulnerability specific predicates

  • Predicate:

    void sslEventHandler() {

    unsigned long i = readVar("i");

    if(i > SSL_MAX_KEY_ARG_LENGTH)

    // "kill process" response strategy

    introvirt.killCurrentProcess();

    }


Experience

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


Predicates they have written

Predicates they have written


Related work

Related work

  • VM introspection [Rosenblum97]

  • VM introspection for intrusion detection [Garfinkel03]

  • Shield [Wang04]

  • Vigilante [Costa05]


Conclusions

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


  • Login