Académique Documents
Professionnel Documents
Culture Documents
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
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...
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 ®ister permutations could still be performed.
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
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. .
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.
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
If the block is application code it reserves a tag before each instruction 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
Dynamically loads an application and mediates application execution by examining and translating an application's instruction before execution on the 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
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
Introducing AES encryption Overriding Strata's default fetch method to decrypt and verify an instruction 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 mprotect system 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.
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..
Linker
Host CPU
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.
Using Strata II
Using Strata
Application Linker Strata New Application
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).
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
Cont..
Implementation
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
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
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
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
Things Left To Do
Get Apache working with ISR Verify that ISR will protect against a buffer overflow attack Collect performance numbers
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
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?
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
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
Thank you!