Efficient Instruction Set Randomization Using Software Dynamic Translation

1
Efficient Instruction Set Randomization Using
Software Dynamic Translation

• Michael Crane
• Wei Hu

2
Outline

• Introduction
• Code injection, ISR
• Problem
• Inefficiency of ISR
• Tools
• Diablo, Strata
• Solution
• Efficient ISR using Strata
• Conclusion

3
Introduction

• Most exploits involve some kind of code injection
• Stack overflows
• Heap overflows
• etc
• Several defenses proposed
• StackGuard
• Address Space Randomization
• ISR

4
Instruction Set Randomization

• A general defense against code injection
• Any application code must be decoded before
  execution
• Code that has been injected will not be encoded
  with the proper key, and will fail
• This 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

5
Disadvantage of ISR

• High overhead
• Every instruction must be decoded at run-time
• Most implementations use an emulator
• i.e. bochs or Valgrind
• Emulators can be 5-100 times slower than native
  execution, depending on the application
• Our goal is to use Strata, a software dynamic
  translation tool, to overcome this overheard

6
Our Approach

• Randomize a binary statically before run-time
• We are using a binary rewriting tool called
  Diablo
• Instructions are XORed with a key
• Derandomize the program at run-time using
  software dynamic translation
• We are using a SDT system called Strata
• All instructions are XORed with the same key

7
Diablo

• A retargetable link-time binary rewriting
  framework.
• 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.

8
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

9
How We Can Use Diablo

• Diablo does a lot of work for us
• Disassembles binaries
• Builds control graph
• Writes binaries
• Modify Diablo to randomize the codes

10
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

11
Strata

• 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

12
Software Dynamic Translation
13
Using Strata
Application
New Application
Linker
Strata
14
Apache Under Strata

• 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

15
How We Can Use Strata

• Implement a custom fetch routine
• Any time an instruction is fetched from the
  binary, XOR it with the key before placing it
  into the fragment cache

16
Implementation
Application
Randomized Application
Diablo
Strata
key
17
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

18
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

19
Shared Libraries

• Functions in glibc are called both by the
  application and by Strata
• Whats wrong?
• Everything outside Strata should be randomized
• If the shared function is randomized, the program
  will crash when Strata calls it

20
Shared Libraries Solution

• Create a separate copy of glibc functions
• Use objcopy to rename all the names of glibc
  functions called by Strata
• The code bloat incurred by separate copy of glibc
  for Strata is about 400Kb
• (Strata doesnt use too much)

21
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

22
Things Left To Do

• Get Apache working with ISR
• Verify that ISR will protect against a buffer
  overflow attack
• Collect performance numbers

23
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

24
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?

25
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

26
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

27
Questions?