Return Oriented Programming (ROP)

• Return oriented programming (ROP) involves constructing needed functionality using existing code within a program's text.

Cat and Mouse

• Defenses against code injection include making the stack/heap non-executable, or hiding libc code addresses using ASLR.
• Attack responses involve jumping/returning to libc, brute force searches or information leaks.
• Another defense is avoiding libc code entirely by using code within the program text.
• Attack response to this is constructing needed functionality using return oriented programming (ROP).

Return-oriented Programming

• Hovav Shacham introduced return-oriented programming in 2007.
• ROP involves stringing together pieces of existing code, called gadgets, instead of using a single library function to run shellcode.
• Challenges include finding gadgets and stringing them together.

Approach

• Gadgets are instruction groups that end with ret.
• The stack serves as the code.
• %esp equals the program counter.
• Gadgets are invoked via ret instruction.
• Gadgets obtain arguments via pop, etc., also on the stack.

Simple example

• A gadget contains assembly instructions such as pop %edx and ret.
• The stack will contain an address to the gadget, as well as the arguments to the gadget.
• The stack pointer (%esp) points to the next gadget in the chain.

Code Sequence

• Assembly code will contain instructions at an address, and use registers as reference.

Equivalent ROP Sequence

• ROP sequences involve invoking chains of gadgets, using stack to supply arguments and addresses.

Whence the gadgets?

• Gadgets can be found to construct an exploit by automating a search of the target binary.
• The search would look for ret instructions and work backwards.
• Shacham found that gadgets in significant codebases are Turing complete.
• Schwartz et al have automated gadget shellcode creation, though not needing Turing completeness.

Blind ROP

• Randomizing the location of the code by compiling for position independence on a 64-bit machine makes attacks difficult.
• Published attacks are often for 32-bit versions of executables.
• Blind ROP involves reading the stack to leak canaries and a return address if a server restarts on a crash but does not re-randomize.
• Next step involves finding gadgets at run-time to effect call to write.
• Final step is to dump the binary to find gadgets for shellcode.

Defeat!

• The blind ROP team developed a remote code exploit for nginx automatically and only through remote interactions.
• The exploit was carried out on a 64-bit executable with full stack canaries and randomization.

Control Flow Integrity

• Stack canaries, non-executable data, and ASLR complicate steps in a standard attack, but don't always stop it.
• The idea is to observe the program's behavior — is it doing what one expect it to?
• If not, code might be compromised.
• Challenges include defining "expected behavior," detecting deviations efficiently, and avoiding compromise of the detector.

Control-Flow Integrity (CFI)

• Expected behavior is defined by Control Flow Graph (CFG).
• Deviations are detected efficiently through In-line Reference Monitor (IRM).
• Compromise is avoided through sufficient randomness and immutability.

Efficient?

• Classic CFI (2005) imposes 16% overhead on average, 45% in the worst case.
• It works on arbitrary executables but is not modular (no dynamically linked libraries).
• Modular CFI (2014) imposes 5% overhead on average, 12% in the worst case.
• It is C only, a part of LLVM, and modular with separate compilation.

Secure?

• MCFI eliminates 95.75% of ROP gadgets on x86-64 versions of SPEC2006 benchmark suite by ruling their use non-compliant with the CFG.
• Average Indirect-target Reduction (AIR) is > 99%.
• AIR is the percentage of possible targets of indirect jumps that CFI rules out.

Call Graph

• A call graph shows the relationships between functions, which functions call which other functions.

Control Flow Graph

• Control flow graph breaks call graph into basic blocks
• Can distinguish calls from returns

CFI: Compliance with CFG

• The call/return CFG is computed in advance during compilation or from the binary.
• Program has to follow the paths allowed by the CFG.
• Direct calls need not be monitored, assuming code is immutable.
• Only indirect calls, like jmp, call, ret with non-constant targets, need monitoring.

In-line Monitor

• The monitor is implemented in-line, as a program transformation.
• A label is inserted just before the target address of an indirect transfer.
• Code is inserted to check the label of the target at each indirect transfer.
• The check should abort if the label does not match.
• The labels are determined by the CFG.

Simplest labeling

• Simplest control flow labeling uses same label at all possible targets of indirect calls

Detailed Labeling

• More detailed control flow labeling uses varying labels for varying call sites
• Return sites from calls to sort must share a label, call targets gt and It must share a label.

Classic CFI Instrumentation

• Instrumentation added to assembly code is to check target label before call happens

Can we defeat CFI?

• There is no way to defeat CFI
• CFI assumes that code is non-executable data
• CFI assumes that code is immutable
• CFI assumes adversary cannot change registers

CFI Assurances

• CFI defeats control flow-modifying attacks such as remote code injection and ROP/return-to-libc.
• CFI doesn't prevent the manipulation of control-flow if is allowed by the labels/graph.
• These are called mimicry attacks, a simple, single-label CFG is susceptible to these.
• CFI has no effect on data leaks or corruptions.

Secure Coding

• Secure coding in C requires developers to maintain discipline, as the language provides few guarantees.
• A good reference is the CERT C Coding Standard.

Design vs Implementation

• Implement coding rules for memory safety errors in the future
• Principles are broader goals, rules are specific practices.

Rule: Enforce input compliance

• Enforcing input compliance sanitizes input

Rule: Enforce input compliance

• Ensure that input is valid
• Not doing so can lead to overflow

General principle: Robust coding

• Robust coding is like defensive driving.
• Each module pessimistically checks its assumed preconditions on outside callers.
• Throw an exception (or even exit) rather than run malicious code, even if clients "know" they won't send a suspicious requests.

Rule: Use safe string functions

• Use string functions that perform length checking and avoid overflows.

Replacements

• Replacements for string oriented functions are as follows:
  • strcat should be replaced with strlcat
  • strcpy should be replaced with strlcpy
  • strncpy should be replaced with strlcpy
  • sprintf should be replaced with snprintf
  • vsprintf should be replaced with vsnprintf
  • gets should be replaced with fgets
• Microsoft versions follow the same pattern but append the _s suffix to the standard function.

Rule: Don't forget NUL terminator

• Strings require one additional character to store the NUL terminator.

Rule: Understand pointer arithmetic

• sizeof() returns number of bytes, but pointer arithmetic multiplies by the sizeof the type.

Defend dangling pointers

• Dangling pointers must be accounted for to prevent crashing

Rule: Use NULL after free

• After freeing a malloced variable, set the pointer to NULL

Manage memory properly

• Use goto chains to avoid duplicated or missed code.
• Coding that encodes try/finally from other languages
• Confirm logic with Gotofail bug

Rule: Use safe string library

• To ensure strings used safely, utilize safey first
• Ex: Very Secure FTP (vsftp) string library

Rule: Favor safe libraries

• Use of libraries that encapsulate well-thought-out design
• Use smart pointers that have only safe operations
• Network with Google protocol buffers, Apache Thrift, with ensure input validation

Rule: Use a safe allocator

• Address Space Layout Randomization (ASLR) affects libraries to make base addresses unpredictable
• Challenge heap-based overflows by making the address returned by malloc unpredictable