GitBook: [master] one page modified

offensive-security/code-execution/binary-exploitation/return-to-libc.md

@@ -9,13 +9,15 @@ The purpose of this lab is to familiarize with a ret-to-libc technique, which is
 * This lab is only concerned with 32-bit architecture.
 {% endhint %}
 
-In a standard stack-based buffer overflow, attacker writes their shellcode into the vulnerable program's stack and executes it on the stack. 
+In a standard stack-based buffer overflow, an attacker writes their shellcode into the vulnerable program's stack and executes it on the stack. 
 
 However, if the vulnerable program's stack is protected \(NX bit is set, which is the case on newer systems\), attackers can no longer execute their shellcode from the vulnerable program's stack. 
 
 To fight the NX protection, a ret-to-libc technique is used that enables attackers to bypass the NX bit protection and subvert the vulnerable program by re-using existing executable code from the standard C library shared object \(/lib/i386-linux-gnu/libc-\*.so\), that is loaded into vulnerable program's virtual memory space.
 
-At a high level, ret-to-libc technique is similar to the regular stack overflow, with one key difference - instead of overwritting the return address with address of the shellcode when exploiting a regular stack-based overflow with no stack protection, in ret-to-libc case, the return address is overwritten with a memory address that points to the function `system(const char *command)` that lives in the `libc`, so that when the overflowed program wants to return, it jumps to the `system()` function and executes the shell command that was passed to the `system()` function as `*command` argument. In our case, we will want the vulnerable program to spawn the `/bin/sh` shell, so we will make the vulnerable program call `system("/bin/sh")`.
+At a high level, ret-to-libc technique is similar to the regular stack overflow, with one key difference - instead of overwritting the return address with address of the shellcode when exploiting a regular stack-based overflow with no stack protection, in ret-to-libc case, the return address is overwritten with a memory address that points to the function `system(const char *command)` that lives in the `libc`, so that when the overflowed program returns, it jumps to the `system()` function and executes the shell command that was passed to the `system()` function as the `*command` argument. 
+
+In our case, we will want the vulnerable program to spawn the `/bin/sh` shell, so we will make the vulnerable program call `system("/bin/sh")`.
 
 ### Diagram
 
@@ -44,7 +46,7 @@ From the above diagram \(after overflow\), if you are wondering why, when lookin
 3. EBP is pushed;
 4. Local variables are pushed.
 
-With the above, it should now be clear why the overflowed stack looks that way - essentially, we manually built an arbitrary/half-backed stack frame for the `system()` function call:
+With the above in mind, it should now be clear why the overflowed stack looks that way - essentially, we manually built an arbitrary/half-backed stack frame for the `system()` function call:
 
 * we pushed an address that contains the string `/bin/sh` - the argument for our `system()` call;
 * we also pushed a return address, which the vulnerable program will jump to once the `system()` call completes, which in our case is the address of the function `exit()`.
@@ -82,7 +84,7 @@ echo 0 > /proc/sys/kernel/randomize_va_space
 
 ![Temporarily disable ASLR](../../../.gitbook/assets/image%20%28857%29.png)
 
-Let's now execute the vulnerable program via gdb \(1\), set a breakpoint on the function `main` \(2\) and continue the execution \(3\):
+Let's now execute the vulnerable program via gdb, set a breakpoint on the function `main` and continue the execution:
 
 ```bash
 gdb vulnerable anything
@@ -102,13 +104,13 @@ checksec
 
 ## Finding system\(\)
 
-By doing:
+In gdb, by doing:
 
 ```csharp
 p system
 ```
 
-We can see, that the function `system` resides at memory location `0xb7e13870` inside the vulnerable program in the `libc` library:
+...we can see, that the function `system` resides at memory location `0xb7e13870` inside the vulnerable program in the `libc` library:
 
 ![system\(\) is located at 0xb7e13870](../../../.gitbook/assets/image%20%28839%29.png)
 
@@ -126,7 +128,7 @@ We want to hijack the vulnerable program and force it to call `system("/bin/sh")
 
 We need to remember that `system()` function is declared as `system(const char *command)`, meaning if we want to invoke it, we need to pass it a memory address that contains the string that we want it to execute \(`/bin/sh`\). We need to find a memory location inside the vulnerable program that contains the string `/bin/sh`. It's known that the `libc` contains that string - let's see how we can find it.
 
-We can inspect the memory layout of the vulnerable program and find the start address of the `libc` \(what memory address inside the vulnerabel program it's is loaded to\):
+We can inspect the memory layout of the vulnerable program and find the start address of the `libc` \(what memory address inside the vulnerable program it's is loaded to\):
 
 ```csharp
 gdb-peda$ info proc map
@@ -166,7 +168,7 @@ x/s 500 $esp
 
 ![](../../../.gitbook/assets/image%20%28849%29.png)
 
-In the above screenshot, we can see that at `0xbffffeea` we have the string `SHELL=/bin/sh`. Since we only need the address of the string `/bin/sh` \(without the `SHELL=` bit, which is 6 characters long\), we know that `0xbffffeea + 6` will give us the exact location we are looking for, which is `0xBFFFFEF0`:
+In the above screenshot, we can see that at `0xbffffeea` we have the string `SHELL=/bin/sh`. Since we only need the address of the string `/bin/sh` \(without the `SHELL=` bit in front, which is 6 characters long\), we know that `0xbffffeea + 6` will give us the exact location we are looking for, which is `0xBFFFFEF0`:
 
 ![/bin/sh as an environment variable inside the vulnerable program at 0xBFFFFEF0](../../../.gitbook/assets/image%20%28850%29.png)
 
@@ -178,11 +180,11 @@ Worth remembering, that we can look for the required string using gdb-peda like
 find "/bin/sh"
 ```
 
-![](../../../.gitbook/assets/image%20%28913%29.png)
+![/bin/sh can be seen in multiple locations in the vulnerable program](../../../.gitbook/assets/image%20%28913%29.png)
 
 ## Exploiting
 
-Assuming we need to send 16 bytes of garbage to the vulnerable program before we can overwrite its return address, and make it jump to `system()` \(located at `0xb7e13870`, expressed as `\x70\x38\xe1\xb7` due to little-endianness\), which will execute `/bin/sh` that's present in  `0xb7f52968` \(expressed as `\x68\x29\xf5\xb7`\), the payload in general form looks like this:
+Assuming we need to send 16 bytes of garbage to the vulnerable program before we can overwrite its return address, and make it jump to `system()` \(located at `0xb7e13870`, expressed as `\x70\x38\xe1\xb7` due to little-endianness\), which will execute `/bin/sh` that's present in  `0xb7f52968` \(expressed as `\x68\x29\xf5\xb7`\), the payload in a general form looks like this:
 
 ```csharp
 payload = A*16 + address of system() + return address for system() + address of "/bin/sh"