G ENESIS : 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

University of Virginia SRS January 2005 PI Meeting2 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

University of Virginia SRS January 2005 PI Meeting3 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

University of Virginia SRS January 2005 PI Meeting4 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

University of Virginia SRS January 2005 PI Meeting5 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 Use software dynamic translation (SDT) to introduce diversity into applications

University of Virginia SRS January 2005 PI Meeting6 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,…

University of Virginia SRS January 2005 PI Meeting7 Modern SDT Systems Daisy Daisy: Dynamic compilation for 100% architectural compatibility, Ebcioglu and Altman, 24 th 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 Micro 18(2), Strata Retargetable and Reconfigurable Software Dynamic Translation Scott, Kumar, Velusamy, et al. CGO Strata: A Software Dynamic Translation Infrastructure, Scott and Davidson, WBT 2001, Barcelona, Spain, 2001.

University of Virginia SRS January 2005 PI Meeting8 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

University of Virginia SRS January 2005 PI Meeting9 Strata

University of Virginia SRS January 2005 PI Meeting10 Using the Strata Framework custom_fetch(Address pc) { if (is_on_stack(pc)) { fail(“Smash!”); } else { return fetch(pc); }

University of Virginia SRS January 2005 PI Meeting11 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

University of Virginia SRS January 2005 PI Meeting12 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.

University of Virginia SRS January 2005 PI Meeting13 Implementing ISR with Strata

University of Virginia SRS January 2005 PI Meeting14 Issues SDT Issues Overhead Run-time overhead Extra code executed Context switches Memory Overhead Recovery Attacking the SDT Debugging Accountability

University of Virginia SRS January 2005 PI Meeting15 Strata Overhead (x86/Linux)

University of Virginia SRS January 2005 PI Meeting16 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

University of Virginia SRS January 2005 PI Meeting17 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

University of Virginia SRS January 2005 PI Meeting18 Effectiveness of ISR Nora Sovarel and David Evans Where’s the FEEB?

University of Virginia SRS January 2005 PI Meeting19 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

University of Virginia SRS January 2005 PI Meeting20 Answer: Slows down an attack about 26 minutes Under the right circumstances…

University of Virginia SRS January 2005 PI Meeting21 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

University of Virginia SRS January 2005 PI Meeting22 Jump Attack: Make Infinite Loop Vulnerable Buffer Overwritten Return Address 0xEB (Jump) 0xFE (-2) Unknown Masks Correct Guess Guessing first 2 byte masks 2 16 Possibilities Need about 2 12 guesses to learn first 2 bytes

University of Virginia SRS January 2005 PI Meeting23 Incremental Jump Attack Vulnerable Buffer Overwritten Return Address 0xEB (Jump) 0xFE (-2) Unknown Masks Correct Guess Guessing first 2 byte masks Overwritten Return Address 0xEB (Jump) 0xFE (-2) Guessed Masks Guessing additional byte masks: < 256 attempts 0xCD (INT)

University of Virginia SRS January 2005 PI Meeting24 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

University of Virginia SRS January 2005 PI Meeting25 False Positives – Good News Can distinguish correct mask using other instructions Try using guessed mask to inject a harmless one-byte instruction Overwritten Return Address 0x90 (NOP) 0xEB (Jump) 0xFE (-2) Guessed Masks

University of Virginia SRS January 2005 PI Meeting26 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 0b xyz  not taken  0x7 0b xyz  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 guesses to get first 2 bytes

University of Virginia SRS January 2005 PI Meeting27 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

University of Virginia SRS January 2005 PI Meeting28 Extended Attack Overwritten Return Address Guessed Masks 0xE9 (Near Jump) 0xCD (INT) 0xEB (Jump) 0x06 32-bit offset (to jump to original return address) “Crash Zone” Expected work: < 16 attempts to find first jumping instruction ~ 8 attempts to determine correct mask

University of Virginia SRS January 2005 PI Meeting29 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%

University of Virginia SRS January 2005 PI Meeting30 Results Average Number of Attempts Key Bytes Acquired (log scale) Jump Attack Return Attack < 31,000 attempts (26 minutes) to acquire 1024 key bytes 255 attempts (50 seconds) to get first byte 1 Jump Attack First 2 bytes: 2027 attempts / byte Next 14 bytes: 222 attempts / bytes Next 1008 bytes: attempts / byte

University of Virginia SRS January 2005 PI Meeting31 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)

University of Virginia SRS January 2005 PI Meeting32 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)

University of Virginia SRS January 2005 PI Meeting33 Better ISR

University of Virginia SRS January 2005 PI Meeting34 Better ISR

University of Virginia SRS January 2005 PI Meeting35 Demonstration

University of Virginia SRS January 2005 PI Meeting36 Learn more about SDT Tutorial at CGO 2005 (March 20 th in San Jose) Profiling Instrumentation Binary translation Security Optimization