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

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


  • 201 Views
  • Uploaded on

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)

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

PowerPoint Slideshow about 'An Attack Simulator for Systematically Testing Program-Based Security Mechanisms' - EllenMixel


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 Security Mechanisms

  • 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: Security MechanismsStack 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 Security Mechanisms

  • 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 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 Security Mechanisms

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 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? Security Mechanisms

  • 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 Security Mechanisms

  • 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 Security Mechanisms

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 Security Mechanisms

  • 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 Security MechanismsAttack 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 Security Mechanisms

  • 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 Security 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 Security Mechanisms

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 Security Mechanisms

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 Security Mechanisms

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 Security Mechanisms

  • 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 Security Mechanisms

  • 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 Security MechanismsAttack 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 Security Mechanisms

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) Security Mechanisms

Reasonable overhead


Results summary l.jpg
Results: Summary Security Mechanisms

  • 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 Security Mechanisms

  • 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 Security Mechanisms

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 Security Mechanisms

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 [] ->


ad