Diversity Algorithms for Worrisome Software and Networks (DAWSON)

1. Diversity Algorithms for Worrisome Software and Networks(DAWSON) James Just, Mark Cornwell, Jason Minto, Art Torrey Global InfoTek, Inc. Karl Levitt, Jeff Rowe, Tufan Demir UC Davis R. Sekar Consultant (SUNY Stony Brook) 27 January 2005

2. Overview • Project overview • Integration framework • Diversity to break exploits • Diversity to break payloads • Framework for analyzing effectiveness • Binary rewriting review • Next steps

3. Problem Space (1) Excessive Homogeneity => Systemic Vulnerability How prevent exponentially cascading failures? • Attacks exploit dense environment with ease to spread fast and/or far • Foreseeable cyber-risks dominated by static, durable monoculture of executables

4. Problem Space (2) Common Mode Failures Impede Intrusion Tolerant Systems • Intrusion tolerant systems are: • Expensive • Have large hw/sw footprints • Assume a priori knowledge of attack modalities • Success depends on availability of spare components • Assumption of independent intrusions/faults is flawed • Availability of diverse commercial spares limits effectiveness even if intrusion tolerance system affordable • Rapid learning of attack signatures for blocking is hard • Custom N-version programming is costly

5. DAWSON Approach • Randomized transforms of Windows executables at runtime • Preserve functionality of executable modules (e.g., dll) • Transform binary code, machine addresses, names, etc • Use annotations to facilitate • Pseudo-random numbers produce unique transformations on each application restart • Network protocol diversity effort replaced by breaking payload execution • Goal: Beat program metric by 10X for large fraction of exploit space if transforms are focused • 100 functional equivalents with no more than 3 susceptible to same exploit as baseline code for most exploits • Low overhead transforms (runtime performance)

6. Attack Space of Interest: Memory Error Exploits Memory corruption attacks • Corrupt target of existing pointer • Compromise security critical data • File names opened for write or execute • Security credentials -- has the user authenticated himself? Corrupt a pointer value Includes common buffer overflows, strncpy(), off-by-one, cast screw-up, format strings, double-free, return to libc, other heap structure exploits • Corrupt code pointer • Return address • Function pointer • Dynamic linkage tables (GOT, IAT) • Corrupt data pointer • Frame pointer • Local variables, parameters • Pointer used to copy input Pointer to injected data • Pointer to existing data • Example: corrupt string arguments to functions so that they point to attacker desired data already in memory, e.g., “/bin/sh”, “/etc/passwd” Pointer to injected code Pointer to existing code

7. Evaluation • Identify assumptions and ROE for possible Red Teaming • Internal testing with • Fabricated applications with known vulnerabilities and exploits • Real applications with known vulnerabilities and exploits • Possible use of Emulab or Deter network emulation testbeds

8. Some Assumptions & Red Team ROEs • Attacks are remote, automated and non-directed • Attacker cannot observe the execution of valid programs without using system calls • Processes cannot transition from user mode to kernel mode without using system calls • Attacker cannot automate non-trivial static analysis of memory contents • Modification is limited to binary (or memory) editing; source code is unavailable

9. Status • Interim products • Native Windows (MFC, .Net) PE File Editor • Transforms • Automated permutation of the Import Address Table in PE files • Automated replacement of DLL names and functions with random strings in PE files • Local variable location modification – not quite automated yet • In-process • Reordering of binary code blocks and insertion of dead code blocks • Asymmetric transformation of function parameters using dummy functions. • New insights on requirements • Address obfuscation (to defeat trivial static analysis of memory) • Fail-crash & detection mechanism (to defeat brute force trial and error) • Non-by-passability of transform mechanisms – Balzer wrapper mechanism – UC Davis investigating option from another project • Because of perceived higher value, shifted some effort to developing diversity to break payloads rather than diversity for network protocols

10. Transition and Future Work • Interim use intermediate products by other SRS contractors • Integrate with follow-on projects/products • If successful • Package for military users • Possible GITI “commercial” product • Possible open source “toolkit” approach • Transition to Microsoft or other software vendors • Some expressions of VC interest • Standard research publications

11. DAWSON Project Schedule & Milestones • Baseline Tasks • 1. Requirement Refinement • Exploit Diversification • 3. Payload Diversification • 4. Integration • 5. T&E • Program Mgt. • Prototypes FY04 FY05 FY06 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 1 2 3

12. GITI

13. Current Attack Problem Software Specification Source Code Machine Code Specification Executable Code Known V-Spec Vulnerability Loader Exploit & Payload Machine-level Code

14. Vulnerability Specification? • All aspects of a program execution which can be exploited by malicious code to gain control of the Program Counter, e.g., • Memory Topology • Stack Specification • System APIs • Application API’s • Libraries • Exception Handling • Etc

15. Breaking the V-Spec Software Specification Source Code Machine Code Specification Executable Code Known V-Spec Vulnerability?? Vulnerability Transforming Loader Machine-level Code Machine-level Code Machine-level Code Doesn’t Match X Machine-level Code Machine-level Code Machine-level Code Machine-level Code Exploit & Payload Machine-level Code Machine-level Code Machine-level Code Machine-level Code Machine-level Code Machine-level Code Machine-level Code Machine-level Code Transform Specifications V-Spec Unknown Until Load-Time

16. Transform Techniques in Literature* • Obfuscation • Layout obfuscation (scramble identifiers, remove comments, change formats) • Control flow obfuscations (Statement grouping, ordering, computation, opaque constructs) • Data obfuscation (Storage, encoding, grouping, ordering) • Preventative transformations (prevent decompilers from operating by exploiting weaknesses) • Inherent (aliases, variable or bogus dependencies, opaqueness side effect & difficulty) • Targeted • Source code • N-version programming • Functional-behavior preserving diversity in components used (e.g., different encryption algorithms, different scales for data such as Celsius or Fahrenheit) • Semantics preserving source code transformations • Place sensitive data (such as function and data pointer) below the starting address of any buffer • Variable ordering • Equivalent instructions • Variable compilation --Variable internal names, padding and addresses, linking orders • Insertion of opaque constructs or other dead code to change memory layout • Binary code • Address transformations (relative and absolute) on binary code • Randomize base address of memory regions (Stack, Heap, DLL, routines/static data in executable) • Permute order of variable/routines (Local variables in stack frame, static variables, routines in shared libraries or routines in executables) • Introduce random gaps between objects (Padding in stack frames, between successive malloc allocation requests, between variables in the static area; Gaps within routines and add jump instructions to skip over gaps) • System resource, system call, or DLL name/address transformation • Instruction set transformation • Static and dynamic binary rewriting *References shown on later slides

17. Multi-Layer Defense Strategy Prevent Remote Exploit of Memory Errors GITI Prevent Injected Code from Properly Executing UC Davis Prevent Access to Windows DLL’s Prevent Use of Windows DLL’s GITI UC Davis Prevent the Bypass of DLL’s

18. Translation Wrapper Diversity System Functional Architecture:Normal Normal user inputs are translated Modified loader transforms original stored program and generates wrapper that retranslates external calls & untranslated so they work User Inputs Other System Resources Original Program Modified Loader Transformed In-memory program Annotation File PRN

19. Translation Wrapper Diversity System Functional Architecture:Initial Exploit Modified loader transforms original stored program and generates wrapper that retranslates external calls Attacker Other System Resources Original Program Modified Loader Transformed In-memory program Some attacks fail because assumed vulnerability is gone Annotation File PRN

20. Untranslation Wrapper Diversity System Functional Architecture:Payload Execution Modified loader transforms original stored program and generates wrapper that retranslates external calls Attacker Other System Resources Original Program Modified Loader Transformed In-memory program Other attacks fail because injected commands are wrong Annotation File PSN

21. DAWSON Implementation Concept (I) Approach eases integration of various transform techniques DAWSON Randomizer PE File Editor Original Binary Program on Disk PE File Macro Randomizer Modified Binary Program in Memory or on disk API PE File Component Randomizers Program Annotation File API API API API Transform Technique 1 Object 1 Transform Technique 2 Object 2 Transform Technique 3 Object 3 o o o o o o PRNG Transform Technique N Object K

22. DAWSON Implementation Concept (2) Manual Approach – How best to automate? Original Binary Code Disassembled Code (Optional) Decomiled Code Structure (Pattern) Analyzer Structure (Pattern) Modifier (Optional) Recompiled Code Reassembled Code Modified Binary Code

23. DAWSON Implementation Concept (2) Automated Runtime Randomization Binary Rewriting Randomizer Modified Binary Code Original Binary Code Disassembled Code (Optional) Decomiled Code Structure (Pattern) Analyzer Structure (Pattern) Modifier Annotation File

24. Automated Defensive Transformations

25. Automated Layout Randomizations

26. Exploit Breaking Transforms • Randomize base of stack by a large number (preferably, by 100MB or more for single-threaded programs) • Randomize locations of installed DLLs • Manage all of the DLLs installed on a system • Ensure that they get mapped to non-overlapping locations • Change the mappings periodically • Need simple management tools to make all of this happen • Randomize location of functions in the executable. • Randomize base of the heap and the distance between two successively allocated heap blocks • Randomize location of static variables in the executable

27. Transform Characterization • Type of transformation? • What object is transformed? • When can transformation occur? • Pre-load, load, post-load? • Are annotations or compiler support required? • What types of exploits, payloads are impacted? • How difficult is implementation of transform?

28. Random Stack Rebasing • Linear Randomization over the Range • 4K Byte Granularity • Effective address domain approximately 1.0 GB limited by the demands of other process segments. • Approximate 256K distinct bases are possible • Two approaches examined* • One approach requires modification of the loader to implement in the NT-2000-XP environments • Second approach increase stack reserve space in PE file and decrements ESP – does not require loader modification *Note that stack rebasing can be implemented directly in the PE file for DOS applications

29. .text Segment .data Segment .rdata Segment .debug Segment Unmapped Memory Stack Commit Stack Reserve Unmapped Memory Heap Reserve Heap Commit Memory Topology 2 GByte User Space (Win32) typical Randomization Domain 0x00041000 0x03600000 0x00100000 Stack Base

30. Modifying Static Variable Locations (1) • Preamble & Postamble code generated by compiler • Code Block built by developer • Padding inserted by compiler Preamble Code Block Postamble Padding

31. Modifying Static Variable Locations (2) • Preamble modified to increase size for local variables • Code Block modified to use new offsets for local variables • Postamble stays unchanged Preamble Code Block Postamble Padding

32. Example: Original Assembly Code Preamble Code Block Postamble Padding

33. Modified Assembly Code Preamble Code Block Postamble Padding

34. Diversification of the Windows Vulnerability Environment Karl Levitt, Hao Chen, Matt Bishop, Zhendong Su, Jeff Rowe, Ivan Balepin, Ebrima Ceesay, Tufan Demir, Bhume Bhumiratana, Lynn Nguyen, Daisuke Nojiri UC Davis Computer Security Lab

35. The Problem • Microsoft Windows provides the ideal conditions for epidemic cyber-attacks • Plenty of software vulnerabilities (root level buffer overflows). • Widespread installation of identical software • Attack prevention in MS Windows is difficult • No protection via compiler modification • No source code for the OS or applications • A single scripted exploit works against • Any machine • All machines

36. Diversification of the Windows Vulnerability Environment • Windows executables typically call API functions for any significant task • All API functions are provided in DLLs. • Load address of API functions is not known until the program loads • Load address of API functions varies from host to host • Major goal of Windows exploits is to locate the addresses of critical DLL functions

37. Multi-Layer Defense Strategy Prevent Remote Exploit of Memory Errors Prevent Injected Code from Properly Executing Prevent Access to Windows DLL’s Prevent Use of Windows DLL’s Prevent the Bypass of DLL’s

38. Outline • How Code Red and Slammer work • Permute IAT and Change DLL name strings: Defeat known attacks • Hypothesized attacks that will succeed • Parameter modification: Padding, transformation • Preventing direct system calls from injected code • Towards quantitative analysis of our approaches • Techniques for binary rewriting • Demonstration

39. How does DLL system work? 80000000 stack kernel32.dll 20000000 LoadLibraryA() 77E9D961 IAT 010031A0 77E9D961 `LoadLibraryA’ .text 77E80000 Call *010031A0 01001000 heap 00070000 65D60000 00000000

40. Code Red Worm stack kernel32.dll Injected code 77E9D961 LoadLibraryA() 20000000 .text EAT `LoadLibraryA’ 77E9D961 01001000 heap `KERNEL32’ 77E80000 00070000 00000000

41. SQL Slammer/Sapphire stack Injected code kernel32.dll 77E9D961 LoadLibraryA() 20000000 .text sqlsort.dll 01001000 IAT 77E9D961 heap 77E80000 00070000 00000000

42. Preventing DLL Access • Add Synthetic Diversity to Windows PE Format • Permutation of the Import Address Table • Random String replacement of DLL names and functions

43. Randomize Plain Text Strings PEB stack Injected code `KERNEL32’ 77E80000 `a7Ly4SZq19’ 77E80000 20000000 kernel32.dll .text IAT LoadLibraryA() 77E9D961 `4Cu74xIpI9q2’ `LoadLibraryA’ EAT Call *010031A0 `4Cu74xIpI9q2’ 77E9D961 `LoadLibraryA’ 77E9D961 01001000 heap `KERNEL32’ `a7Ly4SZq19’ 77E80000 00070000 00000000

44. Permute IAT 80000000 stack Call *010031A0 kernel32.dll 20000000 77E9D961 LoadLibraryA() IAT `LoadLibraryA’ 010031A0 77E90332 .text `GetProcAddress’ 77E9D961 0100308C 77E90332 GetProcAddress() 77E80000 Call *010031A0 Call *0100308C 01001000 heap 00070000 65D60000 00000000

45. Preventing DLL Access • Add Synthetic Diversity to Windows PE Format • Permutation of the Import Address Table • Random String replacement of DLL names and functions

46. Some Assumptions… • Attacks are remote, automated and non-directed • Attacker cannot observe the execution of valid programs without using system calls • Processes cannot transition from user mode to kernel mode without using system calls • Attacker cannot automate static analysis of memory contents • Modification is limited to binary (or memory) editing; source code is unavailable

47. Preventing DLL Access • Add Synthetic Diversity to Windows PE Format • Permutation of the Import Address Table • Random String replacement of DLL names and functions • Add Diversity to Binary Code • Randomize Base Addresses • Reorder code blocks • Interleave nonfunctional code block

48. Hypothesis: Operand hijacking 80000000 PEB stack Injected code 20000000 kernel32.dll LoadLibraryA() 77E9D961 IAT .text 0100308C 77E9D961 77E80000 Call *0100308C 01001000 heap 00070000 65D60000 00000000

49. Binary Transformation 80000000 stack kernel32.dll 20000000 77E9D961 IAT 010031A0 .text 1 3 1 77E80000 2 3 2 65D60000

50. Binary Transformation 80000000 stack kernel32.dll 20000000 77E9D961 IAT 010031A0 .text 3 77E80000 2 1 2 65D60000