1 / 36

G E N E S I S : A Framework For Achieving Component Diversity

G E N E S I S : 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. Overview. Technical objectives Develop tools and techniques for introducing diversity automatically

nitza
Download Presentation

G E N E S I S : A Framework For Achieving Component Diversity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GENESIS: 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

  2. 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 DARPA SRS January 2005 PI Meeting

  3. 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 DARPA SRS January 2005 PI Meeting

  4. 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 DARPA SRS January 2005 PI Meeting

  5. 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 Dynamic diversity • Use software dynamic translation (SDT) to introduce diversity into applications DARPA SRS January 2005 PI Meeting

  6. 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,… DARPA SRS January 2005 PI Meeting

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

  8. 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 DARPA SRS January 2005 PI Meeting

  9. Strata DARPA SRS January 2005 PI Meeting

  10. Using the Strata Framework custom_fetch(Address pc) { if (is_on_stack(pc)) { fail(“Smash!”); } else { return fetch(pc); } DARPA SRS January 2005 PI Meeting

  11. 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 DARPA SRS January 2005 PI Meeting

  12. 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. DARPA SRS January 2005 PI Meeting

  13. Implementing ISR with Strata DARPA SRS January 2005 PI Meeting

  14. Issues • SDT Issues • Overhead • Run-time overhead • Extra code executed • Context switches • Memory Overhead • Recovery • Attacking the SDT • Debugging • Accountability DARPA SRS January 2005 PI Meeting

  15. Strata Overhead (x86/Linux) DARPA SRS January 2005 PI Meeting

  16. 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 DARPA SRS January 2005 PI Meeting

  17. 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 DARPA SRS January 2005 PI Meeting

  18. Effectiveness of ISR • Nora Sovarel and David Evans • Where’s the FEEB? DARPA SRS January 2005 PI Meeting

  19. 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 DARPA SRS January 2005 PI Meeting

  20. Answer: Slows down an attack about 26 minutes Under the right circumstances… DARPA SRS January 2005 PI Meeting

  21. 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 DARPA SRS January 2005 PI Meeting

  22. Jump Attack: Make Infinite Loop Unknown Masks 216 Possibilities Need about 212 guesses to learn first 2 bytes 0xEB (Jump) Vulnerable Buffer 0xFE (-2) Correct Guess Overwritten Return Address Guessing first 2 byte masks DARPA SRS January 2005 PI Meeting

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

  24. 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 DARPA SRS January 2005 PI Meeting

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

  26. 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 0bxyz not taken  0x7 0bxyz 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 25+8 guesses to get first 2 bytes DARPA SRS January 2005 PI Meeting

  27. 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 DARPA SRS January 2005 PI Meeting

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

  29. 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% DARPA SRS January 2005 PI Meeting

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

  31. 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) DARPA SRS January 2005 PI Meeting

  32. 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) DARPA SRS January 2005 PI Meeting

  33. Better ISR DARPA SRS January 2005 PI Meeting

  34. Better ISR DARPA SRS January 2005 PI Meeting

  35. Demonstration DARPA SRS January 2005 PI Meeting

  36. Learn more about SDT • Tutorial at CGO 2005 (March 20th in San Jose) • Profiling • Instrumentation • Binary translation • Security • Optimization DARPA SRS January 2005 PI Meeting

More Related