Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

A Survey on Return Oriented Programming

No description

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of A Survey on Return Oriented Programming

Dynamic Integrity Measurement
Dynamic Integrity Measurement
In order to mitigate ROP new runtime integrity monitoring techniques are proposed.

These techniques use tracking instrumentation binaries based on taint analysis and dynamic tracking

A process model is used to explain the concept of dynamic integrity measurement.

Dynamic taint analysis is marking the untrusted data and sending an alert if the data is misused.
Return-into-libc continued
f7 c7 07 00 00 00 test $0x00000007, %edi
0f 95 45 c3 setnzb -61(%ebp)
Introduction - Arms Race
One of the first forms of ROP

Exploiting the property in x86 architectures

Powerful as code injection attacks

No functions are called whatsoever

Difficult to mitigate this attack
Huge number of unintended sequences

Useful sequences - ends in a

Static analysis tool to find such sequences

A Survey on Return Oriented Programming: Types and Defenses

Types of ROP

Defenses Against ROP


Return-less kernels
Compiler based approach

Targets the basic tool of attackers -

completely from a running kernel

Maximum performance overhead - 5.7%

Generic and Effective
W xor X
Code reuse
High level approach to defeat ROP
Implementation of kBouncer
Example: Original sequence
Starting one byte later
c7 07 00 00 00 0f movl $0x0f000000, (%edi)
95 xchg %ebp, %eax
45 inc %ebp
c3 ret
Return-into-libc continued
Return-into-libc - GALILEO Algorithm
Algorithm data structure - "trie"

First, find a useful sequence

Scan backwards from there to find useful gadgets ending in
Return-into-libc - A trivial example
ROP without Returns
Not using ret but instructions with similar properties

Property 1: transfer control of execution by indirect jump

Property 2: update some processor state and subsequent return will transfer control elsewhere
ROP without Returns
ROP without Returns
Update-load-branch instructions

"pop x; jmp *x - x86 architecture

adds r6,#4; ldr r5,[r6,#124]; blx r5 - ARM

Trampoline - central coordinator

Turing-complete gadget set

Further tough to detect as
instructions are not used
ROP without Returns - Attack architecture
Jump Oriented Programming
No reliance on neither the stack nor

Gadgets end in an indirect branch rather than

Two types of gadgets: Functional, Dispatcher

Functional - perform computations required

Dispatcher - governs control flow
Jump Oriented Programming - Example
Jump Oriented Programming
Gadget Discovery - Algorithm similar to GALILEO

Additions - Viable Gadgets, Heuristics

Viable gadgets - elimination criteria (given address not valid at runtime, target out of bounds etc.)

Heuristics - no modification, self-referential etc.
Control Flow Integrity
Prevent changes to control flow of the program

Control Flow Graph (CFG) determined ahead of time

Forces program to follow the same flow

immediate operand "ID", effect free label ID instruction

control is transferred only if code starts with label ID where ID is the corresponding ID in call in call instruction
Return-less kernels: Techniques
Register Allocation:

Modify register allocation algorithm

If opcodes of allocated registers contain c3 byte, change the allocation

Peephole optimization:

For return opcodes introduced by non-ret instructions

substitute instructions with semantically equivalent instructions which do not contain return opcode
Important Assumptions:
UNQ - unique IDs

NWC - non writable code

NXD - no executable data

average measured overhead - 16% longer execution time

average size of increase in binary - 8%
Replacing the return address with a return index

Return index -> entry in centralized return address table

Return address table - static, generated offline

Without return address, attackers can't control flow as per their wish
Return-less kernels
Return-less kernels: return indirection
Data mapping - monitor address of instructions, value of registers, address of memory access and modify accordingly

Post processing - Data in memory, null bytes, return address
convert ROP shellcode into semantically equivalent code with ROP exploit but does not use ROP

enables existing defense techniques to work with ROP malware

customized debugger - finding locations of first two gadgets

mostly static analysis except for debugger
compiler based approach

comprehensive, transparent, safe solution

Remove unaligned free branch instructions - code rewriting

protect aligned free branch instructions - alignment sleds, frame cookies etc.
deRop - architecture
Control Flow Integrity
identifying locations - buffer, index numbers

vulnerable program is executed and values of these numbers are used to find the location
Execution model - each instruction has explicitly specified successor

Successors have no dependance of location of instruction

highly efficient PVM - central coordinator

fallthrough map - describes execution successor of each instruction
Instruction Location Randomization (ILR)
Randomize location of every instruction

changes "predictable code layout"

no compiler support required, runs on arbitrary executable programs

high degree of entropy

average run-time overhead - 13%
G-Free - Protection mechanisms
Alignment sleds:
sufficiently long sequence of bytes - no effect on execution
instruction sequences

Return Address Protection:
short header - encrypts saved return address
footer - restore return address to its original value

Frame cookies:
Additional header to compute and push a random key generated at runtime

Since gadgets are not removed, there may be gadgets left in the code

For jump offset adjustments, if the opcode appears close to MSB, number of
instructions to be inserted is very high
G-Free: Code rewriting mechanisms
Register reallocation:
Avoid all undesired register pairings that produce

Instruction Transformations:
replace instructions that produce
opcode with semantically equivalents ones that don't produce them

Jump-offset adjustments:
replace immediate values used in jump/call that produce
Instruction Location Randomization (ILR)
Attackers might know unrandomized addresses and use it to inject control transfer to such an address

Many instructions are categorized as "not able to randomize" because of exception handling tables in ELF headers

on-disk size of rewrite rules can be quite high
de-generalizes back to old style of return-into-libc attacks

jump oriented rootkits are possible

is not addresses in this technique

detected return index overflow attempts
Implementation requires complex code analysis

Performance not suitable for real-time enforcement

Not widely deployed due to such issues
Requires dynamic execution of vulnerable program

Output might still be different from traditional shellcode
DynIMA with taint tracking
Address Space Randomization (contd.)
Compile time randomizations are more effective than runtime randomization because it can randomize address at a finer granularity.

The PaX developers suggest that ASLR be combined with crash detection and reaction mechanism called a watcher.

This watcher is used to monitor and catch errors.
Address Space Randomization
Address space randomization is a technique used to fortify systems against buffer overflow attacks.

The value of delta_mmap is found using brute force attack. Then the return-to-libc is mounted to get the shell.

Randomization is done both at compile time and at runtime.
kBouncer is an efficient and fully transparent ROP mitigation technique that does not requires source code or debug symbols.

kBouncer is based on runtime detection of abnormal control transfers using hardware features found on commodity processes.

The limitation of the current prototype is that it does not prevent JOP.
Generalizing ROP to RISC
The demonstration of general ROP on the SPARC architecture, fixed instruction length RISC architecture with structured control flow is done.

Firstly instruction sequences that are suffixes of functions are used.

Secondly between instructions in a gadget structured data flow model that dovetails with the SPARC calling convention is used.

Thirdly a memory-memory gadget set, with registers used only within individual gadgets is implemented.
ROP defender is an immediate and practical solution against conventional ROP attacks based on return instructions.

This ROP defender tool uses techniques such as instrumentation based on just-in-time compiler (jit).

This adds extra code to a programs binary at runtime with the purpose to observe the program’s behaviour during execution.
Generalizing ROP to RISC
The main aim is in constructing a catalog of gadgets capable of simple memory, assignment, mathematical etc.

Once Turing-complete set gadgets are implemented it can be used to form a return-oriented program.

To demonstrate the fundamental power of return-oriented programming on SPARC a C gadget API as well as a compiler is further implemented.
General Architecture of ROPdefender
Arms Race - still continuing
Current defenses - not preventing all attacks, performance overhead, changes to hardware
A possible end - defense technique capturing basic property of ROP used in all attacks
Any Questions?

Thanks for your time!!!
Types of ROP
Ravi Shankar, Shilpa Ramakrishnan
Full transcript