Secure and Practiacl Defence Against CI Attacks Using SDT

7/29/2019 Secure and Practiacl Defence Against CI Attacks Using SDT

1/33

A Secure and Practical Defense Against

Code-injection Attacks using Software

Dynamic Translation


2/33

Contents

Code Injection: The Attack

Prevention Methods Against Code Injection Attacks Various Existing techniques

Basic Instruction Set Randomization (ISR) implementations

A Secure and Practical ISR using Software Dynamic Translation (SDT)

Binary Preprocessing

Virtual Execution Environment for the SDT

Security of the Implemented Scheme

Performance Evaluation


3/33

Code Injection: The Attack

A general term used for many types of attacks which insert code that later

becomes part of an application

The attack utilizes lack of proper input/output validation including:

Format of Data Amount of expected data Values of expected data (for numerical inputs)

Thus, it involves exploiting a vulnerability to inject malicious code into an

executing application and then cause the injected code to be executed.

Common exploits involve stack overflow, heap overflow, etc...


4/33

Prevention Methods Against Code

Injection Attacks I

Various techniques for stopping attackers from running injected code

Many focused on particular areas of memory that are often attacked,

mostly the stack

e.g. StackGuard, Pax

Basic Block Signing: partially implemented in hardware which uses AES

utilizing a hardware key to create signature block to ensure that it has not

been modified

Secure Instruction-set Architecture: creates hashes of groups of

instructions which are checked in hardware before they are allowed to

execute.

System executes instructions in such a way that instruction

scheduling, basic block reordering &register permutations

could still be performed.


5/33

Prevention Methods Against Code

Injection Attacks II

Software Dynamic Translation (SDT) mainly for policy enforcement Using Strata which provides an API to watch sensitive system &

function calls and to alter them or prevent them if they behave

outside the implemented policy

Using static binary rewriting for restrictions on control flow Labels used to ensure that return instructions match valid return sites DynamoRIO used as program shepherding to restrict execution based

on policies (e.g. disallowing modified cache)

Memory protection primitives : to disallow execution from writable memory Protection via hardware and OS, most convenient mechanisms and

should be used if they exist Do not exist in embeded systems -need for an efficient software based

solution


6/33

Instruction Set Randomization (ISR)

A theoretically strong defense against code injection

An encryption algorithm is applied to an application binary to encrypt

the instructions , encrypted application is executed by an emulator

Emulator is augmented to decrypt the instruction before execution

Code that has been injected will not be encoded with the proper

encryption key, and will fail

The approach works regardless of how or where code is injected

However, it does not address other exploits that do not inject code

i.e. return-to-libc attacks


7/33

Legacy ISR Implementations and

Limitations

ISR prototypes on IA-32 instruction set using emulation using XOR

operation to produce the randomized binary

XOR individual bytes of original app program with a one-time pad that is

the length of (New Mexico Uni)

Apply XOR of 32-bit key with 32 bit blocks containing instraction(fragment)

(Columbia Uni)

XOR based encryption susceptible to attack

Use of emulation resulted in high overhead esp in CPU-bound instructions

Both methods assumed execution of decrypted payload would eventually

rise an exception

But non zero probability for code to escape


8/33

A Secure and Practical ISR

Employing a combination of binary rewriting and SDT, on GNU/Linux

Binary Rewriting is used to prepare the binary for strong encryption using AES Introduce the information necessary to detect foreign code

An Efficient SDT is used to provide the necessary virtual execution

environment for safe execution

Loads and encrypts the application Decrypts the instruction

checks their validity prior to execution Thus, it involves exploiting a vulnerability to inject malicious code into an

executing application and then cause the injected code to be executed.

.


9/33

Binary Preprocessing

A retargetable link-time binary rewriting framework called Diablo is used to

prepare the binary for encryption

Only works on statically linked programs.

Its inputs are the object files and libraries from which the program is built,

instead of just the program executable.


10/33

How Diablo Works

Merges code sections of each object file

Disassembles the binary text

Builds a control flow graph Does some optimizations

Reassembles the assembly code

Write to a binary file


11/33

Modifications to Diablo in new ISR

scheme

At the Flattener phase (used to assign linear order to CFG&update offsets

in control transfer) , a function is added which is invoked after linear order

assignment but before offset updates

If the block is application code it reserves a tag before eachinstruction It then aligns the block by padding its beginning with NOPs Finally, it recalculates branch offsets and updates affected instructions

The Assempler phase is modified to fill the placeholder preceding each

instruction with a tag if instruction tagging is enabled

The writer phase is extended to create a new encrypttable section Contains the starting and ending address of each block to be

encrypted


12/33

Strata: A Virtual Execution

Environment of the ISR

A retargatable SDT infrastructure designed to support novel applications Used for various applications like code compression

Dynamically loads an application and mediates application execution by

examining and translating an application's instruction before execution onthe host CPU.

Operates as a co-routine with the application it is protecting

Fragment Cache: Strata managed cache to maintain ranslated application

instruction

Application code and Strata execute in turn via context switch


13/33

Strata

A software dynamic translation infrastructure, written in C and assembly

Main design by Kevin Scott, Jack Davidsons PhD student here at UVa

So far it has been targeted to SPARC, MIPS, and x86 Imposes a translation layer between the executable and the processor

Code fragments are fetched from the binary, optionally translated, and

then placed into a fragment cache

Processor control is switched to the fragment for direct execution


14/33


15/33

Modifications to Strata for New ISR

Implementation I

Two basic modifications: Introducing AES encryption

Overriding Strata's default fetch method to decrypt and verify aninstruction before calling the target machine fetch

First Initialize the system call watch table

Encrypt the application. Obtain a 128-bit encryption key from the pseudo-device

/dev/urandom. Use the mprotectsystem call to set write permission for the text

segment. Use the table of address ranges created by the binary rewriter and

the key to encrypt the applications text. Set the text segment permissions to read only.


16/33

Modifications to Strata for the new ISR

implementation II

First Fetch the next instruction. Fetch the 128-bit aligned block that contains instruction pointed to by

current application PC. Also fetch the next 128-bit aligned block Decrypt the two 128-bit blocks. Check that the instruction tag is correct.

If the tag is incorrect, report an error and dump the current PC and

the plain-text instructions located there. If the tag is correct, call the default target machine fetch function to

retrieve the next instruction. The decoding and translation steps proceed as normal..


17/33

Software Dynamic Translation

Application

Context Management Linker

Memory Management

Cache Management

Strata Virtual CPU

Target Interface

Target-specific Functions

Host CPU

StrataVirtual

Machine


18/33

Using Strata II

IETF has also defined a new protocol known as the label distribution

protocol (LDP) for explicit signaling and management

Extensions to the base LDP protocol have also been defined to

support explicit routing based on QoS requirements.


19/33

Using Strata II

Using Strata

Application

Linker

Strata

New Application


20/33

Apache Under Strata

Resides at the edge of an MPLS network and assigns and removes

the labels from the packets.

Support multiple ports connected to dissimilar networks (such as

frame relay, ATM, and Ethernet).


21/33

Apache Under Strata Cont

We can successfully run Apache under Strata with no randomization

Performance was tested with a tool called Flood that generates

HTTP requests

Native execution

190.05 requests/second

Under Strata

137.00 requests/second

1.39x slowdown


22/33

Cont..

Implementation

Application

Diablo

Strata

key

RandomizedApplication


23/33

Issues with Our Approach

Strata is designed to be linked in directly with the application

Strata must share the process space with the randomized

application

This introduces several problems

Selective randomization

Shared libraries

Program start up and shut down


24/33

Selective Randomization

We have to distinguish the code of the application from that of

Strata, and only randomize the code of the application.

We modified Diablo so that:

it remembers the source object file of every code section

it checks the source object file before randomization and

does nothing if the code is from Strata


25/33

The Issue of Shared Libraries

Functions in glibc are called both by the application and by Strata

Everything outside Strata should be randomized

If the shared function is randomized, the program will crash when

Strata calls it

Solution: create a separate copy of glibc functions

Use objcopy to rename all the names of glibc functions called by

Strata

The space overhead incurred by separate copy of glibc for Strata is

mininal (about 400Kb)

Future plans to make Strata independent of any standard library


26/33

Security of the Implemented scheme

An attacker could guess the instruction tag code but as far as the can't

know the encryption key they can't construct a payload that will be

correctly tagged after decryption

Strata controls access to the fragment cache using the mprotect system

calls

8 bit tag used: 1 in 256 chance that a tag is coincidentally correct

But, the tag for each instruction in a fragment must be correct for strata to

execute the fragment

For a four-instruction fragment, the probability of correct tags is 1 out

of pow(2,32).


27/33

Current Status

We can run real server applications (Apache) under Strata without

randomization

We can successfully randomize and derandomize a simple program

There are still some sharing issues with real programs


28/33

Things Left To Do

Get Apache working with ISR

Verify that ISR will protect against a buffer overflow attack

Collect performance numbers


29/33

Insider Attack

Our current implementation assumes a remote attack, where the

attacker does not have access to the randomized binary

The encryption scheme is simple

The key is stored in the binary itself

We must address these issues in order to protect against an insider

attack


30/33

How Effective is ISR?

Our primary goal was to show an efficient implementation of ISR

Strata can also be modified to check the current PC and reject

execution of any code on the stack or other illegal location

Does this accomplish the same thing at a much lower cost?


31/33

ISR vs. Non-Executable Stack

There are legitimate uses for an executable stack [Cowan 1998]

gcc uses executable stacks for function trampolines for nested

functions

Linux uses executable user stacks for signal handling

Functional programming languages, and some other programs,

rely on executable stacks for run-time code generation

In these cases, ISR can help us differentiate between injected code

and legitimate code on the stack


32/33

Conclusions

Implementing ISR using emulation is very inefficient

Software dynamic translation can be used for a more

efficient approach

However, implementation can be very tricky due to

sharing problems


33/33

Thank you!

Secure and Practiacl Defence Against CI Attacks Using SDT

Documents

Transcript of Secure and Practiacl Defence Against CI Attacks Using SDT