Monoculture and Diversity

1. Nora Sovarel and Joel Winstead 21 September 2004 Monoculture and Diversity Monoculture and Diversity

2. What is monoculture? “the cultivation or growth of a single crop or organism especially on agricultural or forest land” Merriam-Webster Online Monoculture and Diversity

3. Monoculture in Biology The Irish Potato Famine, 1845-1850 • About half of Ireland’s population depended on the potato crop • The fungus Phytophthora infestans appeared in Ireland in 1845 • Every potato farm in Ireland was vulnerable • Consequences for Ireland: • 1 million people died • 1-2 million emigrated Monoculture and Diversity

4. What about computing? Most statistics agree that Microsoft has at least 90% of the OS market. For example: thecounter.com: • Win XP 56% • Win 98 20% • Win 2000 15% • Win NT 1% • Win 95 + Win 3x less than 1% • http://www.thecounter.com/stats/2004/August/os.php Monoculture and Diversity

5. Monocultures in Computing • Operating Systems – 90% Microsoft • Browsers – IE, Opera, Netscape • Web Servers – Apache, IIS • Routers – 85% Cisco • Processors – x86, Sparc Monoculture and Diversity

6. Why are we in this situation? • Users – single interface • System Administrators - uniform software configurations • Software Companies • Lower distribution and maintenance costs • Compatibility and file formats Monoculture and Diversity

7. What are the consequences? • Same vulnerabilities for everyone • One worm/virus for majority of systems • Virus writers also like economy of scale: • “write once, exploit everywhere” Monoculture and Diversity

8. What can we do ? • opposite of monoculture • diversity • more than one Monoculture and Diversity

9. Diversity as a defense If we’re not all running exactly the same code: • A single attack cannot compromise everybody • epidemic attacks cease to scale • An attacker won’t know what specific attack to use against a particular target • targeted attacks become more expensive Monoculture and Diversity

10. How many? Are 10 variants of each piece of software and hardware enough? • normal operations disrupted with only a small fraction of computers attacked • Witty worm • applications show same vulnerabilities across OS's Monoculture and Diversity

11. We need more.... • We need every system to look different to the attacker • We need all systems to look exactly the same to the users and administrators • We need to be able to deploy and patch systems quickly and economically Monoculture and Diversity

12. Can we have the benefits without the disadvantages? • Same user interface • Different vulnerabilities • Can the right kind of diversity be generated automatically, without side-effects? Monoculture and Diversity

13. Roadmap • Threat Model • Classes of attacks • Diversity defences: • Address space randomization • Pointer randomization • Instruction set randomization • Keyed hash functions • Effectiveness of these defences Monoculture and Diversity

14. Threat Model • Threat: automated, destructive worms • Require quick, automated, remote infection • “Write-once, exploit everywhere” • Assume attacker knows code, but not key material • We are not: • defending against local attackers • defending against expensive brute-force attacks • defending against targeted attacks • Goal: make cost of automated infection high • Crashing program is better than spreading worm Monoculture and Diversity

15. Classes of Attacks • Code injection attacks • Existing code attacks • Algorithmic complexity attacks Monoculture and Diversity

16. Code Injection Attacks • Stack Smashing Attack • SQL Code Injection • Perl Code Injection • Double Pointer Attacks Monoculture and Diversity

17. Stack Smashing return addr main(int argc, char *argv[]) { ... foo(a,b,c); ... if (everything_is_kosher) { exec(“/bin/sh”); } } void foo(int a,int b,int c) { char buf[100]; ... gets(buf); ... } argc argv a b c return addr buf[ ] Monoculture and Diversity

18. Stack Smashing return addr main(int argc, char *argv[]) { ... foo(a,b,c); ... if (everything_is_kosher) { exec(“/bin/sh”); } } void foo(int a,int b,int c) { char buf[100]; ... gets(buf); ... } argc argv a malicious payload b c return addr buf[ ] Monoculture and Diversity

19. Stack Smashing return addr • Payload overwrites return address • New address can point to injected code or existing code • The payload can also overwrite local variables • Pointers to code can also occur in other places • virtual functions, callbacks • Runtime type information on the heap can also be overwritten See “Smashing the Stack for Fun and Profit” in Phrack #49 for more argc argv a return addr malicious code b c return addr buf[ ] Monoculture and Diversity

20. Existing Code Attacks • Format String Attack • Data Modification Attack • Integer Overflow • return-to-libc attacks Monoculture and Diversity

21. Why do these attacks work? • The way code, stack, and data are laid out in memory is fairly predictable Monoculture and Diversity

22. Why do these attacks work? • The way code, stack, and data are laid out in memory is fairly predictable: Shared Libraries Stack Heap Code Monoculture and Diversity

23. Defence Through Diversity • Solution: randomise layout of address space: Shared Libraries Shared Libraries Stack Stack Heap Heap Code Code Monoculture and Diversity

24. What does this buy us? • This can be done at link time • low overhead • Attacker must know or guess what address to jump to • The starting addresses of code, stack, heap, and library segments add some entropy • On a 32-bit system, about 16 bits for each segment • Is this enough? Monoculture and Diversity

25. Attacking Address Space Randomization • Attacker needs address of only one function to make successful attack • Information leaks can reveal this • format string vulnerability • 16 bits can be brute-forced • Shacham et al. show how to do this in 216 seconds over a network Monoculture and Diversity

26. Can we use a larger key? • Can’t get more than 20 bits without changing virtual memory system • We can add padding to stack and code • We can rearrange functions and data structures in memory • but this is tricky for shared libraries • But an attacker needs only one address to succeed • 64-bit address spaces may help Monoculture and Diversity

27. Address Space Obfuscation and Randomization • start address • reorder • gaps • encryption Monoculture and Diversity

28. Defenses - Stack • Canary Value • Write/Executable Pages • Padding • Local Variables Reordering • Parameter Reordering Monoculture and Diversity

29. Defenses – Memory Layout Randomization • Base Address Randomization • stack • heap • text • DLL Monoculture and Diversity

30. Defenses – Memory Layout Randomization • Reordering of static variables • Reordering of routines • Gaps in heap • Gaps between routines Monoculture and Diversity

31. Pointer Encryption • Rearranging address spaces doesn’t give us a very large key • Can we have diversity not just in how memory is laid out, but in what pointers mean? • What if we encrypted all pointers in the program? • We could use a larger key • Attacker must guess key in order to overwrite a return address with something meaningful Monoculture and Diversity

32. PointGuard • Developed by Cowan et al. at Immunix • All pointers stored in memory are encrypted • Pointers are decrypted immediately before dereference • Pointers are encrypted before storing in memory • An attacker must guess key in order to generate valid pointer to attack code Monoculture and Diversity

33. PointGuard code transformation • Unlike address space transformations, requires compiler changes • Cleartext pointers appear only in registers • Registers are not vulnerable to modification • Encryption must be fast and efficient • We don’t want to encrypt non-pointer data, because that would mean encrypting the buffer containing the attacker’s pointer • Accessing libraries is tricky Monoculture and Diversity

34. Effectiveness of PointGuard • Overhead is low • but requires recompilation • interaction with non-PG-aware code is tricky • Defends against most code injection and return-to-existing-code attacks • Does not defend against all data modification attacks • Information leaks may reveal ciphertext, allowing attacker to guess key Monoculture and Diversity

35. What if code gets in anyway? • The previous techniques work by preventing an attacker from jumping to malicious code in the system • What if we didn’t think of every way that could happen? • Defense-in-depth: • make sure injected code won’t run no matter how control is transferred Monoculture and Diversity

36. What must an attacker know? • An attacker must know how to write code to run on the targeted system • SPARC exploit code will not run on x86 • What if no two computers had the same instruction set? • It would be difficult or impossible to write exploit code that will run everywhere Monoculture and Diversity

37. Instruction Set Randomization Kc, Keromytis, and Prevelakis: • Encrypt the program’s instructions with a different key for each copy of the program • Decrypt each instruction at runtime immediately before execution • Attacker must know key in order to write code that will decrypt to something meaningful • Unsuccessful attack will cause illegal instruction, address, or raise exception Monoculture and Diversity

38. How many bits do we need? • Strong symmetric cryptography typically requires a 128-bit key or larger to resist known-plaintext attacks • Large performance penalty to decrypt • If we assume attacker doesn’t have our ciphertext, we can use much smaller key • 32-bit XOR may be good enough if our goal is to prevent large-scale automated worms Monoculture and Diversity

39. Encoding schemes • XOR: • each word in legitimate code is XORed with the same key • Bit permutation: • The bits in each word are rearranged according to a key: • log2(32!) = 160 bits, for 32-bit word • Can move bits from one instruction to another • In practice, key size is smaller: • more than one way to encode an instruction • more than one harmful instruction Monoculture and Diversity

40. Variable-sized instructions • x86 instructions vary in size • Some instructions are 1 byte • 8 bit key insufficient • Padding with NOPs has cost • generally requires source code • Solution 1: • Pad branch targets only • Solution 2: • Encrypt words, not instructions Monoculture and Diversity

41. x86 Implementation • Authors modified Bochs x86 emulator to decrypt code at runtime • Encrypted image consisting of kernel and statically-linked binaries • Cost of emulation is high for CPU-bound processes • Not so bad for I/O bound processes • Reprogrammable processors could reduce overhead (TransMeta Crusoe) Monoculture and Diversity

42. Interpreted Languages • Some code injection attacks use VBScript, SQL, Perl, or shell languages • Append key material to keywords: • e.g. foreach becomes foreach12345 • Overhead is negligible • The languages are interpreted anyway • Error messages may reveal key Monoculture and Diversity

43. Libraries • Libraries present a problem: • Use different keys for applications and libraries • Use single key for all system libraries • Change the key from time to time • Or: • Statically link everything so that library code uses same key as application Monoculture and Diversity

44. Other issues • Self-modifying code won’t run (Yes, gcc sometimes generates this) • Significant performance penalty • Attacker with ciphertext could brute-force the key offline • No defense against local attackers • May be okay for defense against worms • Does not resist existing code attacks • Does not resist data corruption attacks Monoculture and Diversity

45. Algorithmic Complexity Attacks • The Linux networking code uses hash tables to classify packets • Hash tables, binary trees, and other data structures have good performance in average case • But poor performance in worst case • An attacker who knew the hash function could deliberately generate collisions • This can force worst-case behavior • This can cause denial of service Monoculture and Diversity

46. Diversity as a Defense • Attacker can find collisions only if he knows hash function • What if every copy used a different hash function? • Solution: keyed hash functions • Every copy uses same code • Every copy uses a different key • Attacker cannot force collisions without key Monoculture and Diversity

47. Effectiveness • The techniques presented are orthogonal • Other attacks: • integer overflow • data modification • Other threat models: • local attacker • determined remote attacker • denial of service Monoculture and Diversity

48. Other approaches • StackGuard, StackShield, MemGuard, etc. • bounds checking, canaries, non-executable stack and heap • Safe library routines, wrappers • Sandboxes and safe languages (Java) • Static analysis to detect (or prove the absence of) buffer overflows Monoculture and Diversity

49. Will this prevent catastrophic failures? 3. Things will be much like they are now: persistent threats, common annoyances, but people will still trust Internet for semi-critical tasks. 4. Technologies have emerged (and been successfully deployed) that make epidemic attacks a thing of the past. The Internet will be trusted for the most critical tasks. Do these techniques give us hope for (4)? Monoculture and Diversity