1. Lecture 18: ROP - Continued CS 2011 Spring 2016, Dr. Rozier

2. ROP

4. 4 Image by Dino Dai Zovi

5. Control Flow Hijack: Always control + computation computation + control shellcode (aka payload)padding&buf 5 Return-oriented programming (ROP): shellcode without code injection

6. ROP Programming 1.Disassemble code 2.Identify useful code sequences as gadgets 3.Assemble gadgets into desired shellcode 6

7. THERE ARE MANY SEMANTICALLY EQUIVALENT WAYS TO ACHIEVE THE SAME NET SHELLCODE EFFECT 7

8. Gadgets A gadget is any instruction sequence ending with ret 8

9. ROP Overview Idea: We forge shell code out of existing application logic gadgets Requirements: vulnerability + gadgets + some unrandomized code History: – No code randomized: Code injection – DEP enabled by default: ROP attacks using libc gadgets publicized ~2007 – Libc randomized – ASLR library load points – Q builds ROP compiler using.text section – Today: Windows 7 compiler randomizes text by default, Randomizing text on Linux not straight-forward. 9

10. Return-Oriented Programming (ROP) Find needed instruction gadgets at addresses a 1, a 2, and a 3 in existing code Overwrite stack to execute a 1, a 2, and then a 3 10 Desired Shellcode Mem[v2] = v1 … argv argc return addr caller’s ebp buf (64 bytes) argv[1] buf %ebp %esp

11. Return-Oriented Programming (ROP) 11 Desired Shellcode Mem[v2] = v1 … argv argc return addr caller’s ebp buf (64 bytes) argv[1] buf %ebp %esp a3a3 v2v2 a2a2 v1v1 a1a1 a 1 : pop eax; ret a 2 : pop ebx; ret a 3 : mov [ebx], eax Desired store executed!

12. Attack Surface: Linux 2/1/201212 Randomized Stack Heap Unrandomized Program Image Libc

13. Attack Surface: Windows 2/1/201213 Randomized Stack Heap Unrandomized Program Image Libc

14. DISASSEMBLING CODE 14

15. Recall: Execution Model 15 Process Memory Stack Heap Processor Fetch, decode, execute read and write Code EIP

16. Disassembly user@box:~/l2$ objdump -d./file... 00000000 : 0:55 push %ebp 1:89 e5 mov %esp,%ebp 3:83 ec 10 sub $0x10,%esp 6:8b 45 0c mov 0xc(%ebp),%eax 9:03 45 08 add 0x8(%ebp),%eax c:03 45 10 add 0x10(%ebp),%eax f:89 45 fc mov %eax,0xfffffffc(%ebp) 12:8b 45 fc mov 0xfffffffc(%ebp),%eax 15:83 e0 01 and $0x1,%eax 18:84 c0 test %al,%al 1a:74 03 je 1f 1c:ff 45 fc incl 0xfffffffc(%ebp) 1f:8b 45 fc mov 0xfffffffc(%ebp),%eax 22:c9 leave 23:c3 ret Address Executable instructions Disassemble

17. ROP Programming 1.Disassemble code 2.Identify useful code sequences ending in ret as gadgets 3.Assemble gadgets into desired shellcode 17 Disassemble all sequences ending in ret

18. ROP: Shacham et al. 1.Disassemble code 2.Identify useful code sequences as gadgets ending in ret 3.Assemble gadgets into desired shellcode 18 Automatic Manual

19. ROP - Defenses

20. Attack Vector Malicious Input Buffer Overflow 20

21. Attacks Timeline 1980 1990 2000 2010 Execute Code on the Stack Return to Unsafe Library (return-to-libc) Make Stack Non-exec (WxorX) Randomize Library Image Base (ASLR) Return to Unsafe User Code Gadgets (Shacham, Q [8,1]) ? 21

22. How Relevant is RoP? Microsoft’s 2012 BlueHat Competition – Focused on RoP Mitigation – $260,000 total for top three solutions Successful attack against 2 nd place solution was published one month later 22

23. Executable Non-Executable indicates info irrelevant to the attack Q’s RoP Attack Stack AddressValue 0028FF8C 0028FF90 0028FF94 0028FF98 0028FF9C 0028FFA0 0028FFA4 0028FFA8 0028FFAC 0028FFB0 0028FFB4 0028FFB8 0028FFBA 0028FFC0 0028FFC4 0028FFC8 Registers eax ebx ecx edx edi esi esp ebp 0x6D8011AC: add esp, 12 0x6D8011AF: retn 0x6D8FF623: mov edx, esi 0x6D8FF625: pop esi 0x6D8FF626: mov eax, ebx 0x6D8FF628: pop ebx 0x6D8FF629: pop ebp 0x6D8FF62A: retn 0x6D802A88: pop edi 0x6D802A89: retn 0x6D81BDD7: pop ecx 0x6D81BDD8: retn 0x6D97ED06: sub ecx, edx 0x6D97ED08: push edi 0x6D97ED09: push ecx 0x6D97ED0A: call [IAT:conn] esp 0x6D78941C: retn 23 Attacker Smashes the Stack!

24. Executable Non-Executable indicates info irrelevant to the attack Q’s RoP Attack Stack AddressValue 0028FF8CGadg1:6D8011AC 0028FF90 0028FF94 0028FF98 0028FF9CGadg2:6D8FF623 0028FFA0 0028FFA4 0028FFA8 0028FFACGadg3:6D81BDD7 0028FFB0 0028FFB4Gadg4:6D802A88 0028FFB8 0028FFBAGadg5:6D97ED06 0028FFC0 0028FFC4 0028FFC8 Registers eax ebx ecx edx edi esi esp ebp Gadg1: 0x6D8011AC: add esp, 12 0x6D8011AF: retn Gadg2: 0x6D8FF623: mov edx, esi 0x6D8FF625: pop esi 0x6D8FF626: mov eax, ebx 0x6D8FF628: pop ebx 0x6D8FF629: pop ebp 0x6D8FF62A: retn Gadg4: 0x6D802A88: pop edi 0x6D802A89: retn Gadg3: 0x6D81BDD7: pop ecx 0x6D81BDD8: retn Gadg5: 0x6D97ED06: sub ecx, edx 0x6D97ED08: push edi 0x6D97ED09: push ecx 0x6D97ED0A: call [IAT:X] Action: Return to first gadget 0x6D78941C: retn eip 24 Action: Throw away top three stack valuesAction: Store esi in edx for later use Action: Store in ecx for later use Action: Push arguments and make unsafe library callAction: Store in edi for later use Attack Success! esp

25. RoP Defense Strategy RoP is one example of a broad class of attacks that require attackers to know or predict the location of binary features Defense Goal Frustrate such attacks by randomizing feature space or removing features 25

26. RoP Defenses: Compiler-based Control the machine code instructions used in compilation (Gfree [2] and Returnless [3]) – Use no return instructions – Avoid gadget opcodes Hardens against RoP Requires code producer cooperation – Legacy binaries unsupported let rec merge = function | list, [] | [], list -> list | h1::t1, h2::t2 -> if h1 <= h2 then h1 :: merge (t1, h2::t2) else h2 :: merge (h1::t1, t2);; Gadget- removing Compiler Gadget-free Binary 26

27. RoP Defenses: ASLR ASLR randomizes the image base of each library – Gadgets hard to predict – Brute force attacks still possible [4] Virtual Address Space 2020 2 32 User Address Space Sys. Address Space 27

28. RoP Defenses: IPR / ILR Instruction Location Randomization (ILR) [5] – Randomize each instruction address using a virtual machine – Increases search space – Cannot randomize all instructions – High overhead due to VM (13%) In-place Randomization (IPR) [6] – Modify assembly to break known gadgets – Breaks 80% of gadgets on average – Cannot remove all gadgets – Preserves gadget semantics – Deployment issues 2020 2 31 main lib3 lib2 lib1 User Address Space 28

29. Goal Self-randomizing COTS binary w/o source code – Low runtime overhead – Complete gadget removal – Flexible deployment (copies randomize themselves) – No code producer cooperation 29

30. Challenge: Binary Randomization w/o metadata Relocation information, debug tables and symbol stores not always available – Reverse engineering concerns Perfect static disassembly without metadata is provably undecidable – Best disassemblers make mistakes (IDA Pro) ProgramInstruction Count IDA Pro Errors mfc42.dll3559061216 mplayerc.exe830407474 vmware.exe364421183 30

31. Unaligned Instructions Disassemble this hex sequence – Undecidable problem FF E0 5B 5D C3 0F 88 52 0F 84 EC 8B Valid Disassembly FF E0jmp eax 5Bpop ebx 5Dpop ebp C3retn 0F 88 52 0F 84 EC jcc 8B …mov Valid Disassembly FF E0jmp eax 5Bpop ebx 5Dpop ebp C3retn 88 52 0F 84 EC mov 8B …mov Valid Disassembly FF E0jmp eax 5Bpop ebx 5Dpop ebp C3retn 52push edx 0F 84 EC 8B … jcc 31

32. Solution: STIR (Self-Transforming Instruction Relocation) Statically rewrite legacy binaries to re- randomize at load-time – Greatly increases search space against brute force attacks – Introduces no deployment issues – Tested on 100+ Windows and Linux binaries – 99.99% gadget reduction on average – 1.6% overhead on average – 37% process size increase on average 32

33. STIR Architecture Binary Rewriter Memory Image Original Application Binary Original Application Binary Static Rewriting Phase Load-time Stirring Phase Self-stirring Binary Self-stirring Binary Conservative Disassembler (IDA Python) Lookup Table Generator Load-time Randomizer (Helper Library) Randomized Instruction Addresses 33

34. Innovation: Disassembly Error Tolerance HexPath 1Path 2Path 3Path 4 FFjmp eax E0loopne 5Bpop 5DL1: pop C3retn 0Fjcc 88mov B0mov 50 FFN/A FF 8BL2: mov Byte Sequence: FF E0 5B 5D C3 0F 88 B0 50 FF FF 8B 34 Disassembled Invalid Included Disassembly jmp eax pop L1: pop retn jcc L2: mov loopne jmp L1 mov jmp L2

35. Static Rewriting Header Import Address Table.data.text Original Binary Block 1 -> 500F86… data -> (8 bytes) Block 2 -> 55FF24… … Rewritten Header Import Address Table.data.told (NX bit set) Rewritten Binary Block 1 -> F4 data -> (8 bytes) Block 2 -> F4 ….tnew NB 1 -> rewrite(Block 1) NB 2 -> rewrite(Block 2) … Denotes a section that is modified during static rewriting 35

36. Load-time Stirring When binary is loaded: – Initializer randomizes.tnew layout – Lookup table pointers are updated – Execution is passed to the new start address 2 0 2 31 main lib3 lib2 lib1 User Address Space 36

37. Computed Jump Preservation.text:0040CC9Bcall eaxFF DO.tnew:0052A1CB.tnew:0052A1CE.tnew:0052A1D2 cmp byte ptr [eax], F4h cmovz eax, [eax+1] call eax 80 38 F4 0F 44 40 01 FF D0 Original Instruction: Rewritten Instructions:.told:00411A40F4 dw 0x534AB9F4 B9 4A 53 00 Rewritten Jump Table:.text:00411A40pop ebp5B Original Possible Target:.tnew:00534AB9pop ebp5B Rewritten Target: 37 eax = 0x411A40 eax = 0x534AB9

38. Gadget Reduction 38

39. Windows Runtime Overhead 39

40. Linux Runtime Overhead 40

41. Conclusions First static rewriter to protect against RoP attacks – Greatly increases search space – Introduces no deployment issues – Tested on 100+ Windows and Linux binaries – 99.99% gadget reduction on average – 1.6% overhead on average – 37% process size increase on average Techniques can be leveraged to machine- verifiable software fault isolation – Reins [7] 41

42. References 1.E. J. Schwartz, T. Avgerinos, and D. Brumley. Q: Exploit hardening made easy. In Proc. 20th USENIX Security Symposium, 2011. 2.K. Onarlioglu, L. Bilge, A. Lanzi, D. Balzarotti, and E. Kirda. G-Free: Defeating return- oriented programming through gadget-less binaries. In Proc. 26th Annual Computer Security Applications Conf., pages 49–58, 2010. 3.J. Li, Z. Wang, X. Jiang, M. Grace, and S. Bahram. Defeating return-oriented rootkits with “Return-less” kernels. In Proc. 5th European Conf. on Computer Systems, pages 195–208, 2010. 4.H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu, and D. Boneh. On the effectiveness of address-space randomization. In Proc. 11th ACM Conf. on Computer and Communications Security, pages 298–307, 2004. 5.J. D. Hiser, A. Nguyen-Tuong, M. Co, M. Hall, and J. W. Davidson. ILR: Where’d my gadgets go? In Proc. IEEE Symposium on Security and Privacy, pages 571–585, 2012. 6.V. Pappas, M. Polychronakis, and A. D. Keromytis. Smashing the gadgets: Hindering return-oriented programming using in-place code randomization. In Proc. IEEE Symposium on Security and Privacy, pages 601–615, 2012. 7.R. Wartell, V. Mohan, K. Hamlen, Z. Lin. Securing Untrusted Code via Compiler- Agnostic Binary Rewriting. Upcoming in Annual Computer Security Applications Conference, Dec. 2012. 8.Shacham, The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86). ACM CCS 2007. 42