Security Summer School

User Tools

Site Tools

session:09

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
session:09 [2020/07/08 13:10]
Rareş-Mihail VISALOM (67101) [Resources] 		session:09 [2020/07/19 12:49] (current)
Line 1: Line 1:
-= 0x08. Return Oriented Programming+====== 0x08. Return Oriented Programming ======
  
-== Resources+===== Resources =====
  
 [[https://security.cs.pub.ro/summer-school/res/slides/11-return-oriented-programming.pdf|Session 08 slides]] [[https://security.cs.pub.ro/summer-school/res/slides/11-return-oriented-programming.pdf|Session 08 slides]]
Line 10: Line 10:
  
  
-=== Executable Space Protection +=== PLT and GOT ===
- +
-The **executable space protection** is an instance of the **principle of least privilege**, which is applied in many security sensitive domains. In this case, the executable space protection is used to limit the types of memory access that a process is allowed to make during execution. A memory region (i.e., page) can have the following protection levels: READ, WRITE, and EXECUTE. The executable space protection mandates that writable regions should not be executable at the same time. +
- +
-The mechanism can be (and was) implemented in many different ways, the most common in Linux being: +
- +
-**NX bit:** This is the easiest method, and involves an extra bit added to each page table entry that specifies if the memory page should be executable or not. This is current implementation in 64-bit processors where page table entries are 8-bytes wide. +
- +
-**Physical Address Extension (PAE):** Besides the main feature that allows access to more than 4GB of memory, the PAE extension for 32-bit processor also adds a NX bit in its page table entries. +
- +
-**Emulation:** The NX bit can be emulated on older (i.e., non-PAE) 32-bit processors by overloading the Supervisor bit ([[http://en.wikipedia.org/wiki/PaX#PAGEEXEC|PaX PAGEEXEC]]), or by using the segmentation mechanism and splitting the address space in half ([[http://en.wikipedia.org/wiki/PaX#SEGMEXEC|PaX SEGMEXEC]]). +
- +
-<note> +
-This security feature gets in the way of **just-in-time (JIT)** compilers, which need to produce and write code at runtime, and that is later executed. Since a JIT compiler cannot run in this kind of secured environment, an application using it is vulnerable to attacks known as **JIT spraying**. The idea was first presented by Dion Blazakis, and is, briefly, a way to force the JIT compiler to produce shellcode. +
- +
-    * Slides: [[http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Slides-v2.pdf|Black Hat & DEF CON 2010]] +
-    * Paper: [[http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Paper.pdf|Interpreter Exploitation. Pointer Inference and JIT Spraying]] +
- +
-</note> +
- +
-There are of course other implementations in different hardening-oriented projects such as: OpenBSD [[http://marc.info/?l=openbsd-misc&m=105056000801065|W^X]], Red Hat [[http://www.redhat.com/magazine/009jul05/features/execshield/|Exec Shield]], PaX (which is now part of [[https://grsecurity.net/|grsecurity]]), Windows Data Execution Prevention ([[http://support.microsoft.com/kb/875352|DEP]]). +
- +
-=== Bypassing NX +
- +
-**ret-to-plt/libc.** You can return to the ''.plt'' section and call library function already linked. You can also call other library functions based on their known offsets. The latter approach assumes no ASLR (see next section), or the possibility of an information leak (will be discussed in the Information Leak session). +
- +
-**Return Oriented Programming (ROP).** This is a generalization of the ret-to-* approach that makes use of existing code to execute almost anything. As this is probably one of the most common types of attacks, it will be discussed in depth in a future section. +
- +
-**mprotect().** If the application is using ''mprotect()'' you can easily call it to modify the permissions and include ''PROT_EXEC'' for the stack. You can also call this in a ''ret-to-libc'' attack. You can also ''mmap'' a completely new memory region and dump the shellcode there. +
- +
-<note> +
-Today we will talk about the first 2 methods to bypass NX. **mprotect()** will be introduced in the next sessions. +
-</note> +
- +
-=== Address Space Layout Randomization (ASLR) +
- +
-Address Space Layout Randomization (ASLR) is a security feature that maps different memory regions of an executable at random addresses. This prevents buffer overflow-based attacks that rely on known addresses such as the stack (for calling into shellcode), or dynamically linked libraries (for calling functions that were not already linked with the target binary). Usually, the sections that are randomly mapped are: the stack, the heap, the VDSO page, and the dynamic libraries. The code section can also be randomly mapped for [[http://en.wikipedia.org/wiki/Position-independent_executable|PIE]] binaries. +
- +
-<note important> +
-Linux allows 3 options for its ASLR implementation that can be configured using the ''/proc/sys/kernel/randomize_va_space'' file. Writing 0, 1, or 2 to this will results in the following behaviors: +
-  * **0**: deactivated +
-  * **1**: random stack, vdso, libraries; heap is after code section; random code section (only for PIE-linked binaries) +
-  * **2**: random heap too +
- +
-</note> +
- +
-Make sure you reactivate ASLR after the previous section of the tutorial, by one of the two options below. +
- +
-If you disabled ASLR system-wide, re-enable it using (root access is required): +
- +
-<code bash> +
-~$ sudo bash -c 'echo 2 > /proc/sys/kernel/randomize_va_space' +
-</code> +
- +
-If you disabled ASLR at shell level, simply **close the shell** such as issuing the ''Ctrl+d'' keyboard shortcut. +
- +
-We can easily demonstrate the effects on shared libraries by running ''ldd'' multiple times in a row on a binary such as ''/bin/ls''. +
- +
-==== PLT and GOT+
  
 ASLR is not the only feature that prevents the compiler and the linker from solving some relocations before the binary is actually running. Shared libraries can also be combined in different ways, so the first time you actually know the address of a shared library is while the loader is running. The ASLR feature is orthogonal to this - the loader could choose to assign address to libraries in a round-robin fashion, or could use ASLR to assign them randomly. ASLR is not the only feature that prevents the compiler and the linker from solving some relocations before the binary is actually running. Shared libraries can also be combined in different ways, so the first time you actually know the address of a shared library is while the loader is running. The ASLR feature is orthogonal to this - the loader could choose to assign address to libraries in a round-robin fashion, or could use ASLR to assign them randomly.
Line 159: Line 101:
  
  
-=== Return Oriented Programming+==== Return Oriented Programming ====
  
 {{ :session:rop.png?nolink&600 |}} {{ :session:rop.png?nolink&600 |}}
  
-==== Motivation+=== Motivation ===
 In the previous sessions we discussed ''ret2libc'' attacks. The standard attack was to overwrite in the following way: In the previous sessions we discussed ''ret2libc'' attacks. The standard attack was to overwrite in the following way:
 <code> <code>
Line 190: Line 132:
 This kind of conflict can be resolved using Return Oriented Programming, a generalization of ''ret2libc'' attacks. This kind of conflict can be resolved using Return Oriented Programming, a generalization of ''ret2libc'' attacks.
  
-==== NOP analogy+=== NOP analogy ===
 While ''ret2libc'' uses functions directly, Return Oriented Programming uses a finer level of code execution: instruction groups. While ''ret2libc'' uses functions directly, Return Oriented Programming uses a finer level of code execution: instruction groups.
 Let's explore an example: Let's explore an example:
Line 263: Line 205:
  
  
-==== Gadgets & ROP chains+=== Gadgets & ROP chains ===
 Now that we have a sort of neutral primitive equivalent to a NOP let's actually do something useful. Now that we have a sort of neutral primitive equivalent to a NOP let's actually do something useful.
 The building blocks of ROP payloads are called gadgets. These are blocks of instructions that end with a 'ret' instruction. The building blocks of ROP payloads are called gadgets. These are blocks of instructions that end with a 'ret' instruction.
Line 365: Line 307:
  
  
-=== Some useful ninja tricks+==== Some useful ninja tricks ====
  
-==== Memory spraying+=== Memory spraying ===
 Let's take the following prog: Let's take the following prog:
 <code c> <code c>
Line 472: Line 414:
  
  
-==== Vulnerable function identification+=== Vulnerable function identification ===
 As you can see from above, the base pointer gets trashed so backtracing is not possible As you can see from above, the base pointer gets trashed so backtracing is not possible
 <code bash> <code bash>
Line 542: Line 484:
  
  
-==== ROP payload debugging+=== ROP payload debugging ===
 When you know what the offending function is, disassemble it and break on "ret" When you know what the offending function is, disassemble it and break on "ret"
 <code bash> <code bash>
Line 607: Line 549:
  
  
-==== checksec in peda+=== checksec in peda ===
 <code bash> <code bash>
 gdb-peda$ checksec gdb-peda$ checksec
Line 618: Line 560:
  
  
-==== gadget finding in peda+=== gadget finding in peda ===
 Apart from **objdump** which only finds aligned instructions, you can also use **dumprop** in peda to find all gadgets in a memory region or mapping: Apart from **objdump** which only finds aligned instructions, you can also use **dumprop** in peda to find all gadgets in a memory region or mapping:
 <code bash> <code bash>
Line 667: Line 609:
 </code> </code>
  
-==== Anti-anti-debugging and others+=== Anti-anti-debugging and others ===
 There can be various annoyances in binaries: **ptrace** calls for anti-debugging, **sleep** calls to prevent bruteforcing or **fork** calls to use child processes to serve requests. There can be various annoyances in binaries: **ptrace** calls for anti-debugging, **sleep** calls to prevent bruteforcing or **fork** calls to use child processes to serve requests.
 These can all be deactivated using **unptrace** (for ptrace) and **deactive** in peda. These can all be deactivated using **unptrace** (for ptrace) and **deactive** in peda.
  
  
-== Challenges+===== Challenges =====
  
-=== 00. Tutorial - Bypass NX Stack with return-to-libc+==== 00. Tutorial - Bypass NX Stack with return-to-libc ====
  
 Go to the ''01-tutorial-ret-to-libc/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]]. Go to the ''01-tutorial-ret-to-libc/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]].
Line 761: Line 703:
  
  
-=== 01. Challenge - ret-to-libc+==== 01. Challenge - ret-to-libc ====
  
 Looks good! Let's get serious and do something useful with this. Looks good! Let's get serious and do something useful with this.
Line 784: Line 726:
 </note> </note>
  
-=== 02. Challenge - no-ret-control+==== 02. Challenge - no-ret-control ====
  
 Go to the ''02-challenge-no-ret-control/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]]. Go to the ''02-challenge-no-ret-control/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]].
Line 792: Line 734:
 Alter the execution of ''force_exit'', in order to call the secret function. Alter the execution of ''force_exit'', in order to call the secret function.
  
-=== 03. Challenge - ret-to-plt+==== 03. Challenge - ret-to-plt ====
  
 Go to the ''03-challenge-ret-to-plt/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]]. Go to the ''03-challenge-ret-to-plt/'' folder in the [[https://security.cs.pub.ro/summer-school/res/arc/09-defense-mechanisms-skel.zip|activities archive]].
Line 850: Line 792:
  
  
-=== 04. Challenge - Gadget tutorial+==== 04. Challenge - Gadget tutorial ====
  
 This task requires you to construct a payload using gadgets and calling the functions inside such that it will print This task requires you to construct a payload using gadgets and calling the functions inside such that it will print
Line 862: Line 804:
 stage B!stage A! stage B!stage A!
 </code> </code>
-=== Bonus Challenge - Echo service+==== Bonus Challenge - Echo service ====
 This task is a network service that can be exploited. Run it locally and try to exploit it. You'll find that if you call system("/bin/sh") the shell is opened in the terminal where the server was started instead of the one where the attack takes place. This happens because the client-server communication takes place over a socket. When you spawn a shell it will inherit the Standard I/O descriptors from the parent and use those. To fix this you need to redirect the socket fd into 0,1 (and optionally 2). This task is a network service that can be exploited. Run it locally and try to exploit it. You'll find that if you call system("/bin/sh") the shell is opened in the terminal where the server was started instead of the one where the attack takes place. This happens because the client-server communication takes place over a socket. When you spawn a shell it will inherit the Standard I/O descriptors from the parent and use those. To fix this you need to redirect the socket fd into 0,1 (and optionally 2).
  
session/09.1594203031.txt.gz · Last modified: 2020/07/08 13:10 by Rareş-Mihail VISALOM (67101)

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki