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 Davidson’s 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 • What’s 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 doesn’t 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?