Buffer overflow exploitation without operating system protections is a well understood subject. But how does one achieve the same results with all protections enabled (N/X, ASLR, …). Hint: re-use what the vulnerable binary offers you.

1. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1
“Mind the Gap”
Security Briefings + Training
May 6th-8th, 2014
Alex Moneger, Security Engineer
ROP ‘n’ ROLL, a peak into modern exploits
May 2014

2. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2
1. Why BoF exploitation doesn’t work anymore
2. OS defenses
3. Return Oriented Programming concepts
4. Attack flow
5. Mitigations

3. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 3

4. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 4
• Short buffer, long string
• Overflow into the stack management zones
• Take control of execution flow
• Return into buffer and execute shellcode
NOP sled Shellcode
SC
Add
ress

5. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 5
• Reliably know the buffer’s address
• Be able to execute code in a data section
• Needs to overwrite return address

6. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 6
• ASLR => buffer address is non-predictable
• NX => Can’t execute shellcode on the stack
• Other compiler level protections I wont mention
• Attacker objective => Bypass ASLR and NX:
Find a spot which uses predictable addresses (bypass ASLR)
Build in memory payload (bypass NX)
• Hard but hard enough?

7. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 7
• Stands for Return Oriented Programming
• Uses your code to get execution
• Control stack pointer register instead of instruction pointer
• Only way to exploit a modern OS
• Used in recent exploits since a few years
• No good mitigation

8. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 8
• ASLR does not randomize .text section
• .text section holds the code of the binary
• Use the target to execute code for us
• Find asm instructions (gadgets) from target to build payload
• Use multiple “stages”

9. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 9
• Looking for gadgets we can re-use
• These come from the target binary itself
• Examples:
# Load a value in register
0x8048502L: pop ebx ; pop ebp ; ret;
# Move a value from register and put it in memory
0x80484feL: add [ebx+0x5d5b04c4] eax ; ret;
# Call function in
0x804c244L: call edx ; leave ; ret;

10. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 10
• Needs gadgets at predictable locations
• Uses the binary itself to execute code
• At first ROP does not execute anything, your code does
• Turn off/change OS protections
• Then execute payload

11. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 11
• Control the stack/heap (as usual)
• Locate a fake stack location
• Use the gadgets previously found to build our payload on the fake
stack
• Transfer control to the fake stack
• Execute payload

12. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 12
Attacker controlled memory
Fake Stack
Code section

13. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 13
• Position independent code (GCC => -pie -fpie):
Randomizes code section (full ASLR)
More expensive at runtime (all addresses are relative)
• No other “real world” mitigations

14. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 14
• Modern attacks can bypass OS protections
• A security bug in your code can be exploited
• Catch and fix security bugs early
• Again: OS protections are not a silver bullet, but they make life
harder for the attacker
• Make them work!

15. © 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 15
Thank you.