Return oriented programming (ROP)

Return oriented programming (ROP)

• 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 x86Stack 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
• 4.
  Attack Approaches Stack Smashing Attack Return-to-libc Borrowed Code Chunks (Gadgets) 1. Stack Smashing 2. Return-to-libc 3. Borrowed Code Chunks
• 5.
  Stack Smashing Overflowdata 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 componentof 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 BlackHat 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