G e n e s i s a framework for achieving component diversity
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

G E N E S I S : A Framework For Achieving Component Diversity PowerPoint PPT Presentation


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

G E N E S I S : A Framework For Achieving Component Diversity. John C. Knight, Jack W. Davidson, David Evans, Anh Nguyen-Tuong University of Virginia Chenxi Wang Carnegie Mellon University. Overview. Technical objectives Develop tools and techniques for introducing diversity automatically

Download Presentation

G E N E S I S : A Framework For Achieving Component Diversity

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


G e n e s i s a framework for achieving component diversity

GENESIS: A Framework For Achieving Component Diversity

John C. Knight, Jack W. Davidson, David Evans, Anh Nguyen-Tuong

University of Virginia

Chenxi Wang

Carnegie Mellon University


Overview

Overview

  • Technical objectives

    • Develop tools and techniques for introducing diversity automatically

    • Formulate theoretical underpinnings of diversity

    • Perform realistic evaluations of the developed techniques

  • Existing practice in diversity

    • Traditional diversity is expensive

      • Done manually

      • Duplicate development and application resources

    • Effectiveness not fully understood

    • Difficult to reason about

    • Realistic evaluation difficult

DARPA SRS January 2005 PI Meeting


Overview1

Overview

  • Technical approach

    • Introduce diversity at compile, link, and execution time

    • Use automatic program transformation techniques

    • Use close coupling of compiler and software dynamic translator to explore novel diversity techniques

  • Major risks and mitigation

    • Unacceptable overhead

    • Unconvincing evaluation

    • Susceptibility to new class of attacks

    • Mitigation

      • Development of theoretic framework

      • Optimization of SDT

  • Quantitative metrics

    • Seed “important” applications with vulnerabilities (known and synthetic)

    • Measure overhead of the diversity techniques

DARPA SRS January 2005 PI Meeting


Overview2

Overview

  • Expected major achievements

    • New framework for achieving practical and effective diversity

    • Defenses against Web application exploits

    • Prototype implementations demonstrating the effectiveness of the framework

  • Task schedule with milestones

    • 6/30/2005

      • Improved Strata VM performance

      • Combination of compile-time and run-time transformations

      • Prototype defenses against web application attacks Attacks against ISR and potential defenses

      • Modeling

      • Demonstration  

    • 12/31/2005

      • Combination of compile-time, run-time, and course-grained source-level diversity

      • Comprehensive evaluation of all techniques

      • Demonstration

DARPA SRS January 2005 PI Meeting


Dynamic diversity

Advantages

Binary only (no source needed)

Wide range of transformations possible

Transformations can be applied (or reapplied) at any point during execution

Handles untrusted code (libraries, third party components)

Prevents exploitation of both unintentional and intentional software vulnerabilities

Disadvantages

Can degrade performance

Debugging difficult

Accountability

Dynamic diversity

  • Use software dynamic translation (SDT) to introduce diversity into applications

DARPA SRS January 2005 PI Meeting


Software dynamic translation

Software Dynamic Translation

  • Layer of software between application binary and the OS/CPU

  • Application’s instructions are examined and modified before being executed on the CPU

  • Uses:

    • Binary migration: Transmeta’s Code Morphing, FX!32, Virtual PC, Daisy, …

    • Emulation and simulation: Embra, Shade,…

    • Optimization: Dynamo, Dynamo/RIO, Mojo,…

    • Emerging domains: security, low power, code compression, systems prototyping,…

DARPA SRS January 2005 PI Meeting


Modern sdt systems

Modern SDT Systems

  • Daisy

    Daisy: Dynamic compilation for 100% architectural compatibility, Ebcioglu and Altman, 24th Annual International Conference on Computer Architecture, 1997

  • Dynamo

    Dynamo: A transparent dynamic optimization system, Bala, Duesterwald, and Banerjia, PLDI 2000,

  • FX!32

    FX!32: A profile-directed binary translator, Chernoff, Herdeg, Hookway, et al, IEEE Micro18(2), 1997.

  • Strata

    Retargetable and Reconfigurable Software Dynamic Translation Scott, Kumar, Velusamy, et al. CGO 2003.

    Strata: A Software Dynamic Translation Infrastructure, Scott and Davidson, WBT 2001, Barcelona, Spain, 2001.

DARPA SRS January 2005 PI Meeting


Strata

Strata

  • Infrastructure for building SDT systems

  • Promotes code reuse by providing common implementation environment for SDT

  • Highly reconfigurable for rapid prototyping of translators

  • Easily retargeted to new platforms, and already supports

    • SPARC/Solaris, MIPS/IRIX, x86/Linux, PowerPC/MacOS

DARPA SRS January 2005 PI Meeting


Strata1

Strata

DARPA SRS January 2005 PI Meeting


Using the strata framework

Using the Strata Framework

custom_fetch(Address pc) {

if (is_on_stack(pc)) {

fail(“Smash!”);

} else {

return fetch(pc);

}

DARPA SRS January 2005 PI Meeting


Strata diversity transformations

Strata diversity transformations

  • Default diversity

    • Address space randomization

      • Code is relocated in F$

      • Run-time stack is modified

    • Control-flow randomization

      • Basic block structure is modified (no unconditional branches, direct function calls are eliminated)

      • Indirect jumps and calls transformed

DARPA SRS January 2005 PI Meeting


Instruction set randomization

Instruction Set Randomization

  • Encrypt application code prior to execution

  • Decrypt code before it is executed

  • Malicious code that is injected through some software vulnerability will be decrypted but because it was not encrypted, the resulting code, will not execute properly

  • See

    • Randomized Instruction Set Emulation to Disrupt Binary Code Inject Attacks, Barrantes, Ackley, Forrest, et. al, CCS 03.

    • Countering Code-Injection Attacks with Instruction-set Randomization, Kc, Keromytis, Prevelakis, CCS 03.

DARPA SRS January 2005 PI Meeting


Implementing isr with strata

Implementing ISR with Strata

DARPA SRS January 2005 PI Meeting


Issues

Issues

  • SDT Issues

    • Overhead

      • Run-time overhead

        • Extra code executed

        • Context switches

      • Memory Overhead

    • Recovery

    • Attacking the SDT

    • Debugging

    • Accountability

DARPA SRS January 2005 PI Meeting


Strata overhead x86 linux

Strata Overhead (x86/Linux)

DARPA SRS January 2005 PI Meeting


Strata overhead x86 linux1

Strata Overhead (x86/Linux)

  • Strata adds about 434K overhead (static)

  • F$ is limited to 4 MB

    • Large enough to run all SPEC and Apache without a F$ flush

  • Size overhead is generally not an issue

DARPA SRS January 2005 PI Meeting


Issues1

Issues

  • ISR-specific issues

    • When to encrypt

    • Effect of executing random instructions

    • Ineffective against attacks that do not involve code injection

    • Strength of encryption technique

DARPA SRS January 2005 PI Meeting


Effectiveness of isr

Effectiveness of ISR

  • Nora Sovarel and David Evans

    • Where’s the FEEB?

DARPA SRS January 2005 PI Meeting


How secure is isr

How secure is ISR?

  • Shacham et. al. [CCS 2004] presented a brute force attack on memory address space randomization

    • 24-bit effective key space

  • Can a similar attack be constructed against instruction set randomization?

    • Larger key space (32 bits - 4K bytes)

    • Need to attack in fragments

    • Need a way to tell if fragment guess is correct

DARPA SRS January 2005 PI Meeting


Answer

Answer:

Slows down an attack about 26 minutes

Under the right circumstances…

DARPA SRS January 2005 PI Meeting


Requirements

Requirements

  • Need a vulnerability

    • Any buffer overflow vulnerability will do

    • Must know the exact memory location

  • Must be able to crash server (lots of times) without re-randomization

    • Possible if server handles requests by forking processes (e.g., Apache)

  • Need to know if server crashes

    • Socket open between attack client and server

DARPA SRS January 2005 PI Meeting


Jump attack make infinite loop

Jump Attack: Make Infinite Loop

Unknown Masks

216 Possibilities

Need about 212 guesses to learn first 2 bytes

0xEB (Jump)

Vulnerable Buffer

0xFE (-2)

Correct Guess

Overwritten Return Address

Guessing first 2 byte masks

DARPA SRS January 2005 PI Meeting


Incremental jump attack

Incremental Jump Attack

Unknown Masks

0xEB (Jump)

0xEB (Jump)

Vulnerable Buffer

0xFE (-2)

Guessed Masks

0xFE (-2)

0xCD (INT)

Correct Guess

Overwritten Return Address

Overwritten Return Address

Guessing additional byte masks: < 256 attempts

Guessing first 2 byte masks

DARPA SRS January 2005 PI Meeting


False positives bad news

False Positives – Bad News

  • Incorrect guesses might produce same behavior as correct guess

    • Injected bytes demask to instruction that produces indistinguishable behavior

      • e.g., conditional jump inst often behaves like jump

    • Injected bytes demask to “harmless” instruction, and subsequently executed instruction is (or behaves like) correct guess

  • One incorrect mask guess will probably disrupt attack code

DARPA SRS January 2005 PI Meeting


False positives good news

False Positives – Good News

  • Can distinguish correct mask using other instructions

  • Try using guessed mask to inject a harmless one-byte instruction

0x90 (NOP)

0xEB (Jump)

Guessed Masks

0xFE (-2)

Overwritten Return Address

DARPA SRS January 2005 PI Meeting


False positives better news

False Positives – Better News

  • Structure of false positives can be used to make guessing more efficient

    • Conditional jump instructions (e.g., JP/JNP)

    • Opcodes 0x70-0x7E are all conditional jumps

    • All are complementary pairs:

      0x7 0bxyz not taken  0x7 0bxyz is taken!

  • 32 guesses that try all values of first 4 bits and last bit always find an infinite loop

    • Need more guesses to determine correct mask

  • Need up to 25+8 guesses to get first 2 bytes

DARPA SRS January 2005 PI Meeting


Scaling the attack

Scaling the Attack

  • Once we have learned enough masks:

    • Use near jump to return location instead of creating infinite loops

    • Fill subsequent instructions with 0xCD bytes

      • 0xCD 0xCD is interrupt instruction guaranteed to crash

  • Package attack code: don’t need to obtain enough masks to hold entire worm, just enough to hold decrypting micro-VM

DARPA SRS January 2005 PI Meeting


Extended attack

Extended Attack

0xEB (Jump)

Expected work:

< 16 attempts to

find first jumping

instruction

~ 8 attempts to determine correct mask

0x06

0xCD (INT)

0xCD (INT)

“Crash Zone”

0xCD (INT)

0xCD (INT)

0xCD (INT)

Guessed Masks

0xCD (INT)

32-bit

offset

(to jump to

original

return

address)

0xE9 (Near Jump)

Overwritten Return Address

DARPA SRS January 2005 PI Meeting


Experiments

Experiments

  • Implemented attack against constructed vulnerable server protected with RISE [Barrantes et. al, 2003]

    • Memory space randomization works!

      • Turned off Fedora’s address space randomization

    • Needed to modify RISE

      • Ensure separate processes use same randomization key (other proposed ISR implementations wouldn’t need this)

  • Able to obtain correct key most of the time

    8 bytes: 99%1024 bytes: 85%

DARPA SRS January 2005 PI Meeting


Results

Results

< 31,000 attempts (26 minutes)

to acquire 1024 key bytes

Jump Attack

First 2 bytes:

2027 attempts / byte

Next 14 bytes:

222 attempts / bytes

Next 1008 bytes:

23.25 attempts / byte

Average Number of Attempts

Jump Attack

Return Attack

1

2

8

16

64

1024

255 attempts

(50 seconds)

to get first byte

Key Bytes Acquired (log scale)

DARPA SRS January 2005 PI Meeting


Solutions

Solutions

  • Attack depends on being able to determine key from one known ciphertext-(likely) plaintext pair (trivial with XOR)

    • Use block cipher or permute ISA to make this hard

    • Strata’s fragment cache makes this possible

  • Attack depends on being able to launch multiple attack attempts against the same key

    • Re-randomize and restart after any process crash (enables easy denial-of-service)

    • Re-randomize frequently (without restarting)

DARPA SRS January 2005 PI Meeting


Improved isr

Improved ISR

  • Use AES

    • Symmetric-key block cipher that can use keys of 128, 192, or 256 bits and encrypts in blocks of 128 bits (16 bytes)

  • Compiler and Diablo cooperate to align all branch targets on 128-bit boundaries

    • Function entry points

    • Pad with no-ops

      • Unconditional/conditional branch targets

      • Indirect branches

      • Return points

    • Strata removes no-ops when building fragment (after encryption)

DARPA SRS January 2005 PI Meeting


Better isr

Better ISR

DARPA SRS January 2005 PI Meeting


Better isr1

Better ISR

DARPA SRS January 2005 PI Meeting


Demonstration

Demonstration

DARPA SRS January 2005 PI Meeting


Learn more about sdt

Learn more about SDT

  • Tutorial at CGO 2005 (March 20th in San Jose)

    • Profiling

    • Instrumentation

    • Binary translation

    • Security

    • Optimization

DARPA SRS January 2005 PI Meeting


  • Login