1. Computer Security 2014 – Ymir Vigfusson Some slides borrowed from David Brumley’s lectures at CMU, and Vitaly Shmatikov’s CS380S

2. 2  In attacks so far, knowing memory addresses is key  In regular stack overflows, find the shellcode buffer  In return-to-libc, know the glibc location of e.g. system()  In heap overflows, know location of return address  In format string attacks, know location of return address  In ROP chains, know addresses of the ROP gadgets  Notice the pattern:  (I) Some malicious code or computation to be run  (II) Divert control flow to address of bad code  This family of attacks often called control flow hijacks

3. 3  Addressed concern (I) through DEP/NX  Prohibit memory from being simultaneously writeable and executable (W^X).  Therefore, attackers can‘t inject or create any new code to execute.  What‘s the issue?  Defeated by return-to-libc and more generally ROP  Recycle old code in organized, nefarious ways  ROP shown to be Turing-complete (!) ▪ Loops and conditional branches Hovav Shacham. The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86), CCS 2005.

4. 4 Image by Dino Dai Zovi, lecture by David Brumley

5. Return oriented programming ROP exploit relies entirely on existing code! c7316931c9dead07beef013 ac978f3ff196569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff19656 9ba83144cc4401018971c73 dead07beef013ac978f3ff19 6569ba83144cc4401018971 c7316931c9dead07beef013 ac978f3ff196569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff19656 9ba83144cc4401018971c73 16931c9dead07beef013ac9 78f3ff196569ba83144cc440 dead07beef013ac978f3ff19 dead07beef013ac978f3ff19 6569ba83144cc4401018971 c7316931c9dead07beef013 ac978f3ff196569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff19656 9ba83144cc4401018971c73 badc0dedead07beef013ac9 78f3ff19dead07beef013ac9 78f3ff196569ba83144cc440 1018971c7316931c9dead07 beef013ac978f3ff196569ba 83144cc4401018971c73169 31c9dead07beef013ac978f3 ff19656dead07beef013ac97 8f3ff196569ba83144cc4401 018971c7316569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff19656 9ba83144cc4401018971c73 16931cad07beef013ac978f3 ff196569ba83144cc44eef01 3ac978f3ff196569ba83144c c4401018971c7316931c9de ad07beef013ac978f3ff1965 Computer memory ff19656dead07beef013ac97 8f3ff196569ba83144cc4401 018971c7316569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff19656 9ba83144cc4401018971c73 16931cad07beef013ac978f3 ff196569ba83144cc44eef01 3ac978f3ff196569ba83144c c4401018971c7316931c9de ad07beef013ac978f3ff1965 c7316931c9dead07beef013 ac978f3ff196569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff19656 9ba83144cc4401018971c73 dead07c0ded13ac978f3ff19 6569ba83144cc4401018971 c7316931c9dead07beef013 ac978f3ff196569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff18f3 ff196569ba831018971c73 16569ba83144cc4401018 971c7316931c9dead07be ef01dead07c0ded13ac3ff 196569ba83144cbadc0de 0x0c0c0c0c

6. 6  Probability of gadgets left in a program being sufficient to spawn a shell (function of prog. size) Call libc functions in 80% of programs >= true (20KB)

7. 7  As defenders, how can we address concern (II)?  Diverting control flow to address of malicious content  One high-level idea: “if we‘re about to run bad code, halt the execution!“  How would you implement this?  Determining whether a program will do a certain thing is undecidable  We need some other ideas...  What about making the addresses hard to guess?

8. 8  Back in the 2000‘s, worms (self-replicating software) would compromise 100,000s of computers  Offsets were the same or similar between all victims  Prompted research into the topic  PaX team released ASLR in Linux in 2001  Idea: simulate NX bit to address concern (I) and then make all addresses as random as possible to harden concern (II)  Challenge: be backward compatible with binaries already compiled

9. 9  PaX: Randomize base addresses for:  Stack segment  Heap segment  Code segment  Global offset table / PLT  Shifted by random constant  x86: 16-bits, 24-bits for stack  amd64: ~40 bits

10. 10 Credit: Gustavo Duarte

11. 11  PaX is an optional patch (used in grsecurity)  A weaker version in Linux kernel (‘05), default since 3.1.1  16-bit randomization of base addresses  Kernel parameter kernel.va_randomize_space ▪ 0 = No randomization. ▪ 1 = Medium randomization: libraries, stack, parts of heap ▪ 2 = “Full“ randomization: libraries, stack, all of heap  Text segment [i.e. code], BSS and Data not randomized without PaX  Microsoft default ASLR in Windows Vista (‘07)  Initially some bias in the randomization (Black Hat ‘07)  Randomization happens at boot time  Stack (13-bits), Heap (5 bits), EXE/DLL (8 bits)  Only applies to files compiled with /DYNAMICBASE flag  OS X has default ASLR since 2011

12. 12

13. 13  Think about modern, sophisticated software  Web browsers, E-mail suites, Word/Excel/Powerpoint, PDF readers (!), Java, Flash players,...  Many of these software have internal languages ▪ Web browsers: HTML/JavaScript ▪ Word/Excel/Powerpoint: Visual Basic ▪ Flash: Actionscript (similar to JavaScript)  ASLR normally engages at the start of an execution ▪ Thus repeated attacks usually have similar addresses  How can we overcome ASLR + DEP now?

14. 14  Information leakage about addresses  Secondary bugs, format strings, /proc/self/maps,...  Gives us sufficient information to produce offsets!  Very common approach in modern exploits  Returning into non-randomized memory  jmp *%esp  Executing non-randomized memory  Some parts of non-PIE program at fixed locations  Not all libraries opt-in to randomization (e.g. JVM)  Brute-force the address  How entropic is the ASLR randomization? (x86 32/64-bit)  PaX 64-bit: 40 bits vs. 28 bits on standard Linux

15. 15  Recall NOP sleds:  We put sleds of NOPs in front of shellcode to reduce guesswork with address offsets  What if we could have tons of NOP sleds and shellcode stored in memory?  Increases chances that a random address contains our malicious payload

16. 16  Use software to spray NOP sleds all over memory!  Example: JavaScript heap spraying var nop = unescape(“%u9090%u9090”) while (nop.length < 0x100000) nop += nop var shellcode = unescape("%uDEAD%uBEEF%..."); var x = new Array () for (i=0; i<1000; i++) { x[i] = nop + shellcode; } heap vtable NOP slide shellcode

17. 17  Many interesting attack vectors  Example: Java Applets disable DEP/NX on every segment, so load an applet to set up smorgasboard of NOP sleds.  Example: Websites may embed.NET DLLs. Create an exceptionally large one...  Heap Feng Shui (Sotirov ’07)  Improve JS heap spraying by noting that heap allocators are deterministic  Addresses can be made predictable

18. 18  Show you an attack against Windows 7  Found in the wild in 2012  Used to hack the Council of Foreign Affairs  Bypasses DEP by using ROP  Bypasses ASLR by using fixed opcodes from Java  Java does not randomize its addresses

19. Exploit for recent attack divelm formel m button Use after free appendChild used by the system 0c0c0c0c CVE-2012-4792 Analogy 8256443

20. c7316931c9dead07beef013 ac978f3ff196569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff19656 9ba83144cc4401018971c73 dead07beef013ac978f3ff19 6569ba83144cc4401018971 c7316931c9dead07beef013 ac978f3ff196569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff19656 9ba83144cc4401018971c73 16931c9dead07beef013ac9 78f3ff196569ba83144cc440 dead07beef013ac978f3ff19 dead07beef013ac978f3ff19 6569ba83144cc4401018971 c7316931c9dead07beef013 ac978f3ff196569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff19656 9ba83144cc4401018971c73 badc0dedead07beef013ac9 78f3ff19dead07beef013ac9 78f3ff196569ba83144cc440 1018971c7316931c9dead07 beef013ac978f3ff196569ba 83144cc4401018971c73169 31c9dead07beef013ac978f3 ff19656dead07beef013ac97 8f3ff196569ba83144cc4401 018971c7316569ba83144cc 4401018971c7316931c9dea d07beef013ac978f3ff19656 9ba83144cc4401018971c73 16931cad07beef013ac978f3 ff196569ba83144cc44eef01 3ac978f3ff196569ba83144c c4401018971c7316931c9de ad07beef013ac978f3ff1965 Computer memory used by the system 0c0c0c0c 0x0c0c0c0c system trusts the reference therefore, system executes

21. Exploit that overcomes ASLR+DEP

22. 22  Program calls malloc(), gets our chunk (still in use)  We put gobs of NOP sleds on heap, so 0x0c0c0c0c likely points at certain offset in a NOP sled  We write 0x0c0c0c0c to a memory address in that chunk later used as a function pointer  So no need to know address of saved %eip !  We get CALL *[%eax+0xcd], point to address of instruction xchgl %eax,%esp; ret in Java library  Java library is at a fixed location, and executable  We are now executing series of ROP instructions from 0x0c0c0c0c.  Some of them will „jump ahead“ using addl %esp, 0xcd  Perform VirtualProtect() using ROP, then shellcode

23. 23  Just-in-time compilers produce executable code  E.g. ActionScript, PDF viewers (Acrobat),...  Attackers can leverage these instructions kind of like ROP  Allows for gradual creation of shellcode in an executable segment

24. 24 B8 D9 D0 54 3C var y = ( 0x3c54d0d9 ^ 0x3c909058 ^ 0x3c59f46a ^ 0x3c90c801 ^ 0x3c9030d9 … MOVL %EAX, 3C54D0D9 XORL %EAX, 3C909058 XORL %EAX, 3C59F46A XORL %EAX, 3C90C801 XORL %EAX, 3C9030D9 35 58 90 3C 35 6A F4 59 3C 35 01 C8 90 3C 35 D9 30 … compiles into

25. 25 B8 D9 D0 54 3C MOVL EAX, 3C54D0D9 XORL EAX, 3C909058 XORL EAX, 3C59F46A XORL EAX, 3C90C801 XORL EAX, 3C9030D9 35 58 90 3C 35 6A F4 59 3C 35 01 C8 90 3C 35 D9 30 … Suppose execution starts here instead FNOP PUSH ESP CMP AL, 35 POP EAX NOP PUSH -0C POP ECX ADD EAX, ECX NOP FSTENV DS:[EAX] Intermediate instructions strike again!