This document discusses Return Oriented Programming (ROP), which is a technique for exploiting software vulnerabilities to execute malicious code without injecting new code. It can be done by manipulating return addresses on the program stack to divert execution flow to existing code snippets ("gadgets") that perform the desired task when executed in sequence. The document covers the anatomy of the x86 stack, common ROP attack approaches like stack smashing and return-to-libc, how gadgets work by chaining neutral instructions, and various defenses such as stack canaries, non-executable memory, address space layout randomization, and position-independent executables.
ROP Exploits: Manipulating Returns to Gain Unauthorized Access
1. Return Oriented Programming (ROP)
INTRODUCTION, EXPLOITATIONS AND COUNTER-MEASURES
Pipat Methavanitpong
Doctoral Student
ppmet.th@vlsi.ce.titech.ac.jp
Kunieda-Isshiki Laboratory
Department of Communications and Computer Engineering
Tokyo Institute of Technology
11/4/2014
2. What is ROP?
A program composes of functions
◦ A lot of Calls and Returns
Manipulating return addresses
Go to other Address / Function / Program
Can be done without injecting new code
Example
◦ [Linux] Opening sh shell
◦ [Windows] Opening a calculator
source: https://en.wikipedia.org/wiki/Return-oriented_programming
3. Anatomy of x86 Stack
Caller • Function Arguments
Callee
• Function Return Address
• Frame Pointer
• Exception Handler Frame
• Locally Declared Variables and Buffers
• Callee Save Registers
Higher Addresses
Grow Downward
Lower Addresses
source: http://msdn.microsoft.com/en-us/library/aa290051.aspx#vctchcompilersecuritychecksindepthanchor3
5. Stack
Smashing
Overflow data in stack to its header
or beyond
Example
• Size unchecked string input/copy
• “HELLOBUG”x5
• Overwrite return address of
DrawLine()
• When DrawLine() returns, it
goes to address of value
“HELLOBUG”
H E L L O B U G
H E L L O B U G
H E L L O B U G
H E L L O B U G
H E L L O B U G
source: https://en.wikipedia.org/wiki/Return-oriented_programming
6. Return-to-libc
Common component of a program
◦ Target once, apply all
Provide handful functions (it’s a library)
◦ system() can be used to execute shell commands
Library’s code is marked as executable
◦ Recent defenses force a restriction on execution on address spaces
◦ Non executable (NX) bit feature is useless
Steps
◦ Exploit a buffer overflow vulnerability to gain flow control
◦ Craft a targeted function’s arguments e.g. “/bin/bash”
◦ Return to the targeted function entry e.g. “system()”
7. Borrowed
Code Chunks
(Gadgets)
Registers tend to be reused
Many chances to access memory
Neutral instructions can serve evil
No need to inject code
Link these together
YOU ARE HACKED!
source: Black Hat 2008 – ROP Exploitation without Code Injection
8. Defenses
Stack Canary
Stack smashing protection
A layer between a buffer and control data
Verify it to confirm stack overflow or not
StackGuard / ProPolice / GS Security Cookie
NX bit
Mark memory as executable or not
Can be hardware implementation or software
(emulated)
GCC FORTIFY_SOURCE
Detect and prevent buffer overflow during
compile-time
Sometimes, buffer size is known
ASCII Zone
Fill memory with NULL character to prevent
string abuse
Address Space Layout Randomization (ASLR)
Random placing program and library code
Position Independent Executable (PIE)
Allow the executable part of a program to be
reallocated everywhere
Section Rearrangement
Mitigate damage of overflow
E.g. data and bss section to the lowest
Overflow does not overwrite other important parts of
program’s sections
9. Further Resources
Black Hat 2008 – ROP Exploitation without Code Injection
SecurityTube – Buffer Overflow Primer Part 8 (Return To Libc Theory)
Marcelo Carvalho – Buffer Overflow with a Practical Example
RSA Conf 2010 – Practical Return-Oriented Programming
Sebastian Krahmer – x86-64 buffer overflow exploits and the borrowed code chunks exploitation technique
Florida State University – Offensive Computer Security Lectures
Black Hat 2004 – A Comparison of Buffer Overflow Prevention Implementations and Weaknesses
OpenRCE – Reversing Microsoft Visual C++ part I: Exception Handling
Fedora – Security Features
Red Hat Magazine – Limiting Buffer Overflow with ExecShield
Microsoft Technet – On the Effectiveness of DEP and ASLR