Return oriented programming

Introduction Return-oriented programming in a nutshell Demonstration Countermeasures Conclusion
Return-oriented programming
Sebastian Neuser
Hackspace Siegen
May 8, 2014
Return-oriented programming Sebastian Neuser

1 Introduction
What is return-oriented programming?
Before we begin...
Examples
History
2 Return-oriented programming in a nutshell
x86 crash course
Stack buﬀer overﬂow
Gadgets

3 Demonstration
ROPgadget – a ROP compiler
Stupid vulnerable program
Showtime!
4 Countermeasures
ASLR and PIE
Stack canaries and shadow stacks
CFI and ROPdefender
5 Conclusion

1 Introduction
Before we begin...
Examples
History
3 Demonstration
4 Countermeasures
5 Conclusion

Buffer overflow vulnerabilities
simple example:
• fixed size character buffer
• program reads a string from the keyboard and copies it to the
buffer without bounds checking
• number of input characters > buffer size ; buffer overflow
• variables on the stack are overwritten – possibly including the
current function’s return address
• best case scenario: SIGSEGV

Return-oriented programming
• generalization of return-to-libc exploitation
• attacker uses buﬀer overﬂow-vulnerability or something similar
to inject return addresses into the stack
• return-to-libc-exploits chain together calls to library
functions (libc in most cases)
• return-oriented exploits jump a few instructions before a
function’s ret to perform small operations
By carefully chaining together such jumps, an attacker can perform
arbitrary computations!

Why care?
• 45% of all recorded security vulnerabilities in Ubuntu:
; buffer overflow vulnerabilities
• buffer overflow exploits have been implemented in numerous
malicious programs across different platforms
• Return-oriented programming:
• probably the most advanced buffer overflow exploitation
technique so far
• developed and refined over decades

Before we begin...
Terms of service
• Although I don’t intend to, unfortunately I tend to
• become overzealous,
• talk too fast and
• speak with a slur.
; Please insult me, if I do!
• By sitting here and listening to the talk, you agree that
• you will not use the knowledge provided here to harm anyone,
• I am not responsible for anything you break while messing
around with the techniques I present,
• vim is the name of the one true editor,
• proprietary software is inherently evil.
• Feel free to ask questions at any time.

Before we begin...
Stack diagrams
Stack diagrams are depicted from the stack’s top to bottom:
pointers addresses values
stack top 0xbf8c73c0:
0xbf8c73c4:
0xbf8c73c8:
0x1337c0de
0xdeadc0de
0xdeadbeef

Before we begin...
Platform
Examples and demo compiled and tested with
• gcc version 4.7.2
• gdb version 7.4.1
• 32 bit Debian GNU/Linux 7.1
; instruction set architecture: IA-32
• Intel Core 2 Duo P7450

Examples
Computer worms
• The Morris worm aka. ”Great Worm”
• utilized a buffer overflow-vulnerability in the fingerd program
on Unix systems
• rendered infected systems unusable within 90 minutes
• The Slammer worm
• used buffer overflow-vulnerabilities in Microsoft’s ”SQL Server
2000” and ”Desktop Engine 2000”
• infected roughly 75000 servers in approximately 30 minutes
• caused network overloads on a great scale
• The Sasser worm
• exploited a vulnerability in Microsoft’s LSASS
• caused systems to shut down

History
Timeline of buffer overflow exploits
1988 Morris worm
1996 Aleph One: ”Smashing The Stack For Fun And Profit”
1997 Solar Designer: return-to-libc basics
1998 Solar Designer: security patch for the Linux kernel
2000 PaX: Implementation of W⊕X
2001 Nergal: function chaining with return-to-libc
2007 Hovav Shacham: ”Return-into-libc without function calls”
; return-oriented programming
since more and more proof, that return-oriented programming is a
real threat

1 Introduction
x86 crash course
Gadgets
3 Demonstration
4 Countermeasures
5 Conclusion

x86 crash course
Register set
%eax holds the return value of a function call.
%ebx holds a pointer to some data.
%ecx is used for counters in string- and loop instructions.
%edx holds a I/O pointers.
%esi is the source pointer in some instructions.
%edi is the destination pointer in some instructions.
%ebp is the stack frame- or base pointer.
%esp is the stack pointer.
%eip is the instruction pointer.
%eflags is the status and control register.

x86 crash course
Instruction set
mov %esp, %ebp Copies the stack pointer %esp to the base
pointer %ebp.
push %ebp Updates the stack pointer %esp and writes
the value of %ebp to the new top of the stack.
pop %ebp Reads the value at the top of the stack – the
memory location that %esp points to, writes
it into %ebp and discards the value from the
stack by adjusting %esp.
call func Pushes the return address, which is the ad-
dress of the next instruction (%eip+5) onto
the stack and jumps to the instruction la-
beled by ”func:”.
ret Pops the return address from the top of the
stack and writes it into %eip.

x86 crash course
The stack
• data section in a process’ address space
• contains local variables and buﬀers
• arguments to function calls and return addresses are also
implemented using the stack
• x86-family of CPUs:
• stack grows from higher to lower memory addresses
• memory is addressed byte-wise
; push decrements %esp by 4, pop increments %esp by 4

x86 crash course
Function calls – cdecl
• parameters are pushed to the stack in reverse order
• call pushes the address of the next instruction onto the stack
• function prologue (enter):
• save the base pointer %ebp
• copy %esp to %ebp for base pointer addressing
• decrement %esp to allocate stack memory for local variables
• function epilogue (leave):
• discard local variables by copying %ebp to %esp
• restore %ebp by popping it from the stack
• ret pops the return address oﬀ the stack and jumps to it

x86 crash course
Function calls – stack diagram
%esp
%ebp
0xbf8c73d0:
0xbf8c73d4:
local var 0
saved %ebp

x86 crash course
%esp
%ebp
0xbf8c73cc:
0xbf8c73d0:
0xbf8c73d4:
parameter 2
local var 0
saved %ebp

x86 crash course
%esp
%ebp
0xbf8c73c8:
0xbf8c73cc:
0xbf8c73d0:
0xbf8c73d4:
parameter 1
parameter 2
local var 0
saved %ebp

x86 crash course
%esp
%ebp
0xbf8c73c4:
0xbf8c73c8:
0xbf8c73cc:
0xbf8c73d0:
0xbf8c73d4:
parameter 0
parameter 1
parameter 2
local var 0
saved %ebp

x86 crash course
%esp
%ebp
0xbf8c73c0:
0xbf8c73c4:
0xbf8c73c8:
0xbf8c73cc:
0xbf8c73d0:
0xbf8c73d4:
return addr
parameter 0
parameter 1
parameter 2
local var 0
saved %ebp

x86 crash course
%esp
%ebp
0xbf8c73bc:
0xbf8c73c0:
0xbf8c73c4:
0xbf8c73c8:
0xbf8c73cc:
0xbf8c73d0:
0xbf8c73d4:
saved %ebp
return addr
parameter 0
parameter 1
parameter 2
local var 0
saved %ebp

x86 crash course
%esp,%ebp 0xbf8c73bc:
0xbf8c73c0:
0xbf8c73c4:
0xbf8c73c8:
0xbf8c73cc:
0xbf8c73d0:
0xbf8c73d4:
saved %ebp
return addr
parameter 0
parameter 1
parameter 2
local var 0
saved %ebp

x86 crash course
%esp
%ebp
0xbf8c73b4:
0xbf8c73b8:
0xbf8c73bc:
0xbf8c73c0:
0xbf8c73c4:
0xbf8c73c8:
0xbf8c73cc:
0xbf8c73d0:
0xbf8c73d4:
local var 1
local var 0
saved %ebp
return addr
parameter 0
parameter 1
parameter 2
local var 0
saved %ebp

Before...
%esp
%ebp
0xbffff8b4:
0xbffff8b8:
0xbffff8bc:
...
0xbffff93c:
0xbffff940:
0xbffff944:
buffer[0]
buffer[1]
. . .
local var 1
local var 0
saved %ebp
return addr

Meanwhile...
%esp
%ebp
0xbffff8b4:
0xbffff8b8:
0xbffff8bc:
...
0xbffff93c:
0xbffff940:
0xbffff944:
buffer[0]
buffer[1]
. . .
local var 1
local var 0
saved %ebp
return addr

Boom!
%esp
%ebp
0xbffff8b4:
0xbffff8b8:
0xbffff8bc:
...
0xbffff93c:
0xbffff940:
0xbffff944:
buffer[0]
buffer[1]
. . .
local var 1
local var 0
saved %ebp
return addr

Gadgets
What is a gadget?
• attacker searches for short instruction sequences that perform
small tasks and end with ret
; for example poping some values into registers
• gadget: combination of one or more addresses of short
instruction sequences and the values that they should pop oﬀ
the stack
• payload: chain of gadgets

Gadgets
A very simple gadget
ret addr
. . .
{prev gadg}
0x0000002a
{next gadg}
. . .
pop %eax
ret

1 Introduction
3 Demonstration
Showtime!
4 Countermeasures
5 Conclusion

ROPgadget
• finds and lists gadgets that are available in a specified binary
• constructs shellcode, a payload that opens a network socket
or user-specified opcodes
• prints out python commands that can be embedded in a
payload generation script
• searches and prints out addresses of instructions/opcodes and
strings in a binary

log.h
1 //// io.c ////
2
3 // Appends the buffer to the log-file specified by the path
4 void append_log(char* buffer, char* path);
5
6 // Reads an input string to the buffer until EOF is read
7 void read_string_till_eof(char* buffer);
8
9
10
11 //// util.c ////
12
13 // Checks the program arguments
14 void check_args(int count, char* vector[]);
15
16 // Returns a string that describes the current timestamp
17 char* get_time_string(void);

log.c
1 #include <string.h>
2 #include "log.h"
3
4 int main(int argc, char* argv[])
5 {
6 check_args(argc, argv);
7
8 char buffer[512];
9 char logfile_path[32];
10
11 strcpy(logfile_path, argv[1]);
12 if (!strcasestr(logfile_path, ".log"))
13 strcat(logfile_path, ".log");
14
15 read_string_till_eof(buffer);
16 append_log(buffer, logfile_path);
17 return 0;
18 }

io.c
1 #include <stdio.h>
2 #include "log.h"
3
4 void append_log(char* buffer, char* path)
5 {
6 FILE* fp = fopen(path, "a");
7 fprintf(fp, "%s: %sn", get_time_string(), buffer);
8 fclose(fp);
9 }
10
11 void read_string_till_eof(char* buffer)
12 {
13 int c;
14 while ((c=getchar()) && c != EOF) {
15 *buffer++ = c;
16 }
17 printf("n");
18 }

util.c
1 #include <stdio.h>
2 #include <stdlib.h>
3 #include <string.h>
4 #include <time.h>
5
6 void check_args(int count, char* vector[])
7 {
8 if (count != 2) {
9 printf("Usage: log <log file>n");
10 exit(0);
11 }
12 }
13
14 char* get_time_string(void)
15 {
16 time_t timestamp = time(NULL);
17 char* time_string = ctime(&timestamp);
18 time_string[strlen(time_string)-1] = ’0’;
19 return time_string;
20 }

Showtime!
The fun part...
”For a moment, nothing happened.
Then, after a second or so, nothing continued to happen.”
- Douglas Adams, The Hitchhiker’s Guide to the Galaxy

1 Introduction
3 Demonstration
4 Countermeasures
ASLR and PIE
CFI and ROPdefender
5 Conclusion

ASLR and PIE
ASLR and PIE
• Address Space Layout Randomization
• Position Independent Executable
• take eﬀect at load and link time during program startup
• in the PaX implementation, the addresses of the following
segments are randomized:
• .text-segment of the binary (; executable code)
• dynamically linked libraries
• the stack
• the heap
• libraries in themselves are not randomized
; randomization can be overcome by brute-force attacks
and/or through information leakage

Stack canaries – Explanation
• canary word: word between local variables of a function and
the return address
• during function prologue: canary word is placed on the stack
and backed up in a diﬀerent location
• during function epilogue: canary word is veriﬁed through
comparison with the stored value
• word has changed (; the canary is dead )
; program is terminated with a warning message
• Example: StackGuard

Stack canaries – Diagram
%esp
%ebp
0xbf9358bc:
...
0xbf935924:
0xbf935928:
0xbf93592c:
buﬀer
. . .
canary
saved %ebp
return addr

Shadow stacks
• TRUSS: maintains shadow stack, which stores return
addresses
• function prologue: modiﬁed to push the correct return address
onto the shadow stack
• epilogue: compares return addresses
• mismatch ; program termination and error signal

CFI and ROPdefender
Control Flow Integrity
• control flow graph maps all function calls
• function prologues and epilogues are modified at runtime
• targets of call and ret instructions are correlated with the
anticipated control flow in the graph
• opcodes do not match ; program is aborted
• significant computational overhead with a factor typically in
the range of [1.5, 3.5]

CFI and ROPdefender
ROPdefender
• ROPdefender also maintains a shadow stack
• capable of detecting unintended instruction sequences
• return address of every call instruction is pushed onto the
shadow stack
• every ret instruction: comparison of the destination address
to the top of the shadow stack
• program is aborted if the addresses do not match
• computational overhead similar to CFI

1 Introduction
3 Demonstration
4 Countermeasures
5 Conclusion

Summary
• long evolution from direct code injection to ROP
• applicable to many popular architectures
• quite complex technique
• relatively recent ; few eﬀective countermeasures
• frameworks for automation of payload generation
• ; serious threat!
• But: It’s fun!

Thanks for your attention.
Questions?

Return oriented programming

More Related Content

What's hot

Viewers also liked

Similar to Return oriented programming

More from hybr1s

Recently uploaded

Return oriented programming