An Attack Simulator for Systematically Testing Program-Based Security Mechanisms - PowerPoint PPT Presentation

An attack simulator for systematically testing program based security mechanisms l.jpg
Download
1 / 26

  • 182 Views
  • Uploaded on
  • Presentation posted in: Pets / Animals

An Attack Simulator for Systematically Testing Program-Based Security Mechanisms. Ben Breech Lori Pollock. Mike Tegtmeyer. University of Delaware. Army Research Lab. Insecure Programming Practices. Lead to malicious and costly exploits Zotob worm, 2005 ($10,000 - $100,000 / company)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

An Attack Simulator for Systematically Testing Program-Based Security Mechanisms

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


An attack simulator for systematically testing program based security mechanisms l.jpg

An Attack Simulator for Systematically Testing Program-Based Security Mechanisms

Ben Breech

Lori Pollock

Mike Tegtmeyer

University of Delaware

Army Research Lab


Insecure programming practices l.jpg

Insecure Programming Practices

  • Lead to malicious and costly exploits

    • Zotob worm, 2005 ($10,000 - $100,000 / company)

    • Sasser worm, 2004 (kept ~40 Delta planes on ground, shutdown part of UK Coastguard)

  • Examples:

    • gets()

    • strcpy()

    • strncpy() (with wrong n)


Example attack stack smashing l.jpg

Example Attack: Stack Smashing

Runtime Stack

Caller

int f (parameters)

{

local_vars

char buf2 [5];

gets (buf2) // vulnerability

….

}

0x1200

return address

f

local vars

buf2


Possible solutions l.jpg

Possible Solutions

  • Fix vulnerability

    • Can be expensive to locate

  • Rewrite entire code with more secure language/libraries

    • Really expensive

  • Use security mechanism to prevent exploit


Security mechanisms l.jpg

Security Mechanisms

  • Any procedure in program’s environment to prevent successful exploitation of a vulnerability

  • Program based security mechanisms compiled into program

  • Problem: Testing of program based security mechanisms tends to be poor


Example security mechanism propolice l.jpg

Example Security Mechanism: ProPolice

Runtime Stack

Caller

int f (parameters)

{

local_vars

char buf2 [5];

gets (buf2) // vulnerability

….

}

0x1200

return address

f

canary

canary

local vars

buf2

(Etoh and Yoda, 2000)


Current testing of security mechanisms l.jpg

Current testing of security mechanisms

Implement

Mechanism

Exploit

no

Attack

Prevented?

Execute

Vulnerable Prog w/

Sec. Mechanism

Compile

yes

Vuln.

Prog.c


What s wrong with security mechanism testing l.jpg

What’s Wrong with Security Mechanism Testing?

  • Limited amount of “exploitable” programs available

  • Not a lot of testing performed

  • Some mistakes may go unnoticed

    • movb instead of movl

      Our research: create attack simulator to test program based security mechanisms


Goals of security mechanism testing l.jpg

Goals of Security Mechanism Testing

  • Systematic -- insert attacks at any appropriate point

  • Reliable -- accurately report effectiveness of security mechanism tested

  • Low Overhead -- should be efficient and have reasonable overhead


Testing framework l.jpg

Testing Framework

Test Case

Existing

Input

Program w/

Sec. Mechanism

Attack

Spec

Attack

Simulator

Coverage

Report

Monitor

Oracle

Test

Report

Framework

(Breech and Pollock, SESS 2005)


Attack simulator approach l.jpg

Attack Simulator Approach

  • Utilize a dynamic compiler to analyze code during execution

  • Test security mechanisms by dynamically adding code to simulate attack

    • No modification of program code

    • Allows testing of mechanisms without vulnerable programs


Architecture of attack simulator l.jpg

Architecture of Attack Simulator

Dynamic Compiler

Program

w/ Sec. Mech.

Create Basic Block

Attack Simulator

Should

Attack?

Program

Input

yes

no

Insert

Attack

Execute

Block on CPU


Recovering during testing l.jpg

Recovering During Testing

  • Most attacks terminate test run

    • Only do one attack / test run

  • Can “recover” from some simulated attacks by undoing damage done

    • Enables more efficient testing of security mechanisms by avoiding startup costs

  • Requires some extra code to be compiled into program


Testing stack smashing mechanisms l.jpg

Testing Stack Smashing Mechanisms

  • Goal: modify return address

    • each function call is possible attack point

  • 3 modes of testing

    • Direct -- only modify return address

    • Tailored -- modify enough to trigger security mechanism

    • Random -- overflow a buffer by writing random values into it


Attack mode direct l.jpg

Attack Mode: Direct

Runtime Stack

Modify return address directly

Caller

0x1200

0x5555

return address

  • Final outcome identical to stack smashing

  • Can recover

  • Does not exactly simulate stack smashing attack

Current

0xff12

canary

local vars


Attack mode tailored l.jpg

Attack Mode: Tailored

Runtime Stack

Modify both return address and canary (tailor attack to sec. mechanism)

Caller

0x1200

0x5555

return address

  • Mechanism should identify all such attacks

  • Can recover

  • Does not exactly simulate stack smashing attack

Current

0xff12

0xf0ba

canary

local vars


Attack mode random l.jpg

Attack Mode: Random

Runtime Stack

Write random values into (and beyond) local buffer

Caller

yz

0x1200

uvwx

return address

  • Exactly simulates buffer overflow

  • Can’t recover

qrst

Current

canary

0xff12

mnop

abcd

efgh

ijkl

local vars


Evaluation questions l.jpg

Evaluation Questions

  • How well does the attack simulator identify attack points and provide systematic testing?

  • How well do some known security mechanisms identify attacks?

  • How much overhead is incurred?


Evaluation methodology l.jpg

Evaluation Methodology

  • Implemented attack modes as DynamoRIO1 modules

  • Security Mechanisms

    • ProPolice2 from GCC 4.1

    • RAD3 (testing details in paper)

  • Executed 4 C programs

    • None had known vulnerabilities

    • ~1k - 10k LOC

1 (Bruening et al. CGO 2003)

2(Etoh and Yoda, 2000)

3(Chiueh and Hsu, ICDCS 2001)


Results identifying attack points l.jpg

Results: Identifying Attack Points

Found almost all attack points in direct and tailored modes

  • Missed main


Results propolice detection of simulated attacks l.jpg

Results: ProPolice Detection of Simulated Attacks

ProPolice detected all attacks it should have

  • 4 nondetected strcpy wrote to global variables (can’t be used for stack smashing attack)


Results tailored mode overhead seconds l.jpg

Results: Tailored Mode Overhead (seconds)

Reasonable overhead


Results summary l.jpg

Results: Summary

  • Attack Simulator identified almost all possible attack points (missed main)

  • ProPolice detected all attacks designed to detect

  • Reasonable overhead for attack simulator


Conclusions and future work l.jpg

Conclusions and Future Work

  • Presented attack simulator to provide more systematic testing of security mechanisms

    • Demonstrated on known security mechs.

    • Does not require vulnerable programs

  • Future work:

    • Simulate other attacks (function pointers, etc)

    • Seed faults in security mechanisms to further evaluate attack simulator


Example vulnerability l.jpg

Example Vulnerability

Caller AR

42

int blah (int a, int b, int c)

{

char buf1 [3];

int z;

char buf2 [5];

gets (buf2)

….

}

c ->

6

b ->

a ->

7

return address ->

0x1200

QRST

saved fp ->

0x150

MNOP

blah AR

JKL

buf1 [] ->

z ->

FGHI

Input: ABCDEFGHIJKLMNOPQRSTUVWX

ABCDE

buf2 [] ->


Example mechanism propolice l.jpg

Example Mechanism: ProPolice

Caller AR

42

c ->

int blah (int a, int b, int c)

{

char buf1 [3];

int z;

char buf2 [5];

gets (buf2)

….

}

6

b ->

a ->

7

return address ->

UVWX

0x1200

saved fp ->

0x150

QRST

MNOP

canary

blah AR

JKL

buf1 [] ->

z ->

FGHI

Input: ABCDEFGHIJKLMNOPQRSTUVWX

ABCDE

buf2 [] ->


  • Login