Diversity Algorithms for Worrisome Software and Networks (DAWSON)

1. Diversity Algorithms for Worrisome Software and Networks(DAWSON) James Just, Nathan Li Global InfoTek, Inc. Karl Levitt, Jeff Rowe, Tufan Demir UC Davis R. Sekar Consultant (SUNY Stony Brook) 12 July 2005

2. Overview • Project overview • Layer 1 Diversity: Prevent exploitation • Layer 2 Diversity: Accept exploitation, but prevent the successful execution of injected code • Transforms implemented and ongoing Key: randomization • Analytic results • Testing status and results • Demo tonight

3. 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 Common Mode Failures => Intrusion Intolerance Intrusion tolerant systems depend on redundant components Assumption of independent intrusions/faults is flawed Limited availability of diverse, functionally equivalent software Rapid learning of attack signatures for blocking is not easy Problem Space

4. DAWSON GoalandApproach • Break exploitation of memory errors in monocultures through run-time injection of synthetic diversity • Deliver defense in depth for Windows executables that break exploits, break payloads, prevent bypass, etc. • Preserve functionality of executables • Transform absolute memory addresses, names, order, etc • Randomize relative memory addresses • Annotation files (e.g., Vulcan-ized)can facilitate some advanced transforms without source code • Pseudo-random numbers produce unique transformations on each restart of application • DAWSON objective: Beat program metric by 10X for large fraction of exploit space • 100 functional equivalents with no more than 3 susceptible to same exploit as baseline code for non-data attacks • Low overhead transforms (<10% runtime performance)

5. 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 Point to injected data • Point 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” Point to injected code Point to existing code

6. Translation Wrapper Diversity System Functional Architecture Address randomization does not remove vulnerability but makes effect of attack unpredictable Normal user inputs work Attacker Modifications transform original stored program User Inputs Other System Resources Original Program Modified PE File, Loader & System Calls Optional Annotation File Transformed In-memory program Some attacks fail because vulnerability is not at assumed address Other attacks fail because injected commands are wrong PRNG* *Pseudo-Random Number Generator

7. 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

8. Characterizing DAWSON’s Defense-In Depth Techniques Attack Depth Exploit – Layer 1 Payload – Layer 2 OS Depth Defense Techniques USER.EXE Randomize Stack Base and Allocation Randomize Code Location Randomize Heap Base and Allocation Address Resolution USER.DLL Rebase DLL SYSTEM.DLL SYSTEM.SYS Non-Bypassability

9. Evaluation Plan • Analytic study determines impact and size of implemented randomizations • Live exploit testing using: • Real applications with known vulnerabilities and exploits • Synthetic applications with new vulnerabilities and exploits (non-stack smashing attacks) • Emulab network testbed • Varied randomization settings to explore effectiveness • Red Team for sophisticated unknown attacks (e.g., derandomizing) and bypass testing

10. Status (Interim Products) • Integrated automated transforms • Randomization of most DLL locations • Randomized stack base address • Randomized heap address and frames • Automated permutation of the Import Address Table in PE files • Automated replacement of DLL names and functions with random strings in PE files • Analysis of exploit effort to break randomization • Synthetic application with advanced memory error vulnerabilities and associated exploits • Automated testing configuration for Emulab • Native Windows (MFC, .Net) PE File Editor

11. Status (In-Process) • Kernel32 and ntdll relocation – not automated yet • PEB obfuscation • SEH monitoring • Reordering of binary code blocks and insertion of dead code blocks • Local variable location modification – not quite automated yet • Asymmetric transformation of function parameters using dummy functions. • Fail-crash & detection mechanism (to defeat brute force trial and error) • Memory protection to defeat scanning attacks • Evaluating non-bypassable mechanisms • Balzer wrapper mechanism • UC Davis investigating option from another project • Red Team testing

12. Remaining Risks and Mitigations • Most problems have been solved since last meeting • Remaining risks • Randomizing ntdll and kernel32 • Randomizing base of executables without source • Bypassability • Derandomizing attacks • There exists undocumented Windows tables with DLL location information that we are unaware of

13. Transition • Intermediate products available for use 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

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

15. Layer 1: Address Randomization to Break Exploits • Dynamic Run Time Randomization • User Mode Function Hooking • Randomizations - Stack randomization - Heap randomization - DLL Base Randomization

16. Stack Randomization • Two levels of stack randomization are applied • Stack base randomization through hooking stack space function • Stack frame randomization by inserting fake Thread_START_ROUTINE

17. Stack Randomization Problem: user has no control over stack addresses Solution 0x80000000 CreateThread (…,ThreadStartProc,…) Hook and Randomize BaseAddress …… Stack Randomized Address BaseCreateStack(….) …… Default Stack NtAllocateVirtualMemory(…, *BaseAddress,..) 0x00000000

18. Stack Randomization(cont) Problem: user has no control over stack addresses Solution CreateThread (…,ThreadStartProc,…) Stack ThreadStartProc FakeThreadStartProc Stack F1 ThreadStartProc Hook and Provide a FakeThreadStartProc With Random sized stack space F2 F1 F3 F2 Stack Start Proc Randomization F3

19. Heap Randomization • Heap Base Randomization - Heap API call format: NTAPI RtlCreateHeap_HOOK( unsigned long Flags, PVOID Base, unsigned long Reserve, unsigned long Commit, BOOLEAN Lock, PRTL_HEAP_DEFINITION RtlHeapParams)

20. R A N D O M I Z E D L A Y E R Lilo.exe Inject Randomization DLL Heap API NTDLL.dll Windows Process Heap Randomization (cont) • Heap APIs in NTDLL hooked to randomize the Windows heap management behavior • Heap base • Random sized header and tail in heap block • Randomized magic number embedded in head/tail

21. DLL Base Randomization Problem: user has no control over DLL addresses Solution 0x80000000 LoadLibrary(MyDLL) …… Hook and Randomize BaseAddress MyDLL LdrMapDLL(……) Randomized Address …… Default MyDLL NtMapViewofSection(…,*BaseAddress,…) 0x00000000

22. DLL Base Randomization • DLLs aligned on 64k boundaries - working to change this through “junk code” insertion • Does not work for ntdll and kernel32 rebase from user mode hooking - kernel driver/system call hooking approach is being explored. - Another technique used in Layer 2 defense

23. Performance Impact * Data collected on a Pentium 4 1.2GHz CPU 768M

24. Layer 2- Diversity to Break Malicious Payloads • 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 • Our Approach: Introduce synthetic diversity into the Windows DLL system, preventing injected code from locating and executing any system calls.

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

26. Some Assumptions… • Attacks are remote, automated and non-directed • Injected code defenses are limited to binary (or memory) modification; source code is unavailable • Attacker cannot automate static analysis of memory contents • 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

27. 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

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

29. 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 binary code blocks • Interleave nonfunctional code blocks into binaries

30. 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

31. IAT Permutation – The Numbers • IAT’s might have 100s of function addresses; 1/100th chance of guessing correctly when selecting at random. • IAT padded with dummy addresses pointing to alarm functions. 64K addresses means 1/64K chance of guessing right; 99.8% chance of tripping an alarm.

32. IAT Masking • IAT values are overwritten with trampoline addresses • Addresses point to memory with indirect jumps to DLL functions using computed addresses • Randomly selecting IAT entries never works. • The value of the address never appears in the instructions. • Complex static analysis of binary code is required to recover DLL addresses.

33. 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 binary code blocks • Interleave nonfunctional code blocks into binaries

34. 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

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

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

37. Challenges in Binary Rewriting 80000000 stack kernel32.dll 20000000 77E9D961 Indirect Jumps IAT 010031A0 .text 3 1 JMP EAX Call EBX X 1 77E80000 jmp EAX call EBX 2 Function Pointers 3 2 65D60000

38. Binary Rewriting using Exceptions Exception Handler with Address Map stack IAT IAT .text .text Address Map 1 3 2 2 1 3 2

39. Binary Rewriting with Vulcan • PHOENIX – Microsoft’s next generation compiler technology. • Vulcan is the binary editing facility built into PHOENIX. • Infrastructure for binary analysis and transformation

40. Static Modification Binary PDB file Updated Binary Program Rep. Parse Abstract Rep. Reader Disassemble

41. Binary rewriting with Static modification Reordering basic blocks Insert dead codes 55 push ebp 8B mov ebp, esp EC 83 sub esp, 16 EC 16 55 push ebp 90 nop 8B mov ebp, esp EC 90 nop 90 nop 90 nop 83 sub esp, 16 EC 90 nop 90 nop 16 55 push ebp 8B mov ebp, esp EC call 0x780654 83 sub esp, 16 EC 16 55 push ebp 8B mov ebp, esp 84 incl ebx 55 push eax 83 sub esp, 16 EC 16 0X780654: 84 incl ebx 55 push eax C2 retn

42. Binary rewriting with Static modification Randomize base of static variables A tag is assigned during compilation process to all Operands of Intermediate Representation Update the tag if the base of static variables changes Analyze and Make corresponding changes in the code with the tag information

43. Binary Rewriting – The Numbers • Program address space is ~2Gb • Assume a program size of ~200 Mb • Dummy padding with alert functions and fail-crash code size is ~1.8 Gb • Attacker has a 1 in 500 Million chance of getting the right DLL address; 90% chance of tripping an alarm per try.

44. Additional Details… Are there other places to find DLL addresses? • Kernel32.DLL is always loaded in a fixed memory location during boot • Manually modify the Windows boot procedure to rebase kernel32.dll on boot. • All processes contain a “Process Environment Block” (PEB) data structure with all dll addresses to improve the performance of the loader.

45. PEB Masking • Loader Information provides easy access to DLLs • TEB is always at 0x7ffdf000 • Path exists from TEB to all DLL base addresses • After the image is loaded, this information is very rarely needed (e.g., during a dynamic load) • DLL addresses in the PEB are overwritten with random values after program loading.

46. Preserving Functionality • Include a Wrapper around loader functions • Restores information prior to certain Kernel32 functions (e.g., LoadLibrary) • Re-hides the information prior to passing control back to the (vulnerable) application

47. Case study: MS Blaster PEB stack Injected code `KERNEL32’ 77E80000 20000000 .text kernel32.dll LoadLibraryA() 77E9D961 01001000 heap EAT `LoadLibraryA’ 77E9D961 00070000 77E80000 00000000

48. Preventing DLL Access • Key points • No runtime execution infrastructure • No performance impact upon running programs • Access prevention is policy free

49. Preventing DLL Bypass • Problem: Attacker can provide assembly components that implement some DLL functions making direct low level (undocumented) Windows system calls • Trap System Interrupts for Runtime Checking

50. Signing System Calls by Location • Post-load pre-execute binary instrumentation • What is instrumented: • System call ID. • In Linux system call ID is stored in %eax and interrupt is issued. • We substitute original syscall_id with signed_id (stored in %eax prior to interrupt) • Advantage: • Preserve system consistency. Programs are modified only after they’re loaded. foo.exe Foo in memory Normal load and link Instrument in memory execute • Address is 32-bit address of the location where system call is made • syscall_id is only 8 bit (only about 200 syscalls exist in Linux) Ek = Fast trapdoor permutation with secret key k. F:{0,1}32 {0,1}24 token = F(Address) %eax = signed_id = Ek(token || syscall_id)