Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-21 20:23:18 +00:00
Code Issues Projects Releases Packages Wiki Activity

Minor corrections

Browse source
This commit is contained in:
7Rocky 2024-04-06 14:59:16 +02:00
parent 8b39e454a4
commit 09561c1a93
1 changed files with 10 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
reversing-and-exploiting/linux-exploiting-basic-esp/stack-overflow/README.md
View file

@ -18,10 +18,10 @@ Other ways to support HackTricks:
A **stack overflow** is a vulnerability that occurs when a program writes more data to the stack than it is allocated to hold. This excess data will **overwrite adjacent memory space**, leading to the corruption of valid data, control flow disruption, and potentially the execution of malicious code. This issue often arises due to the use of unsafe functions that do not perform bounds checking on input.
The main problem of this overwrite is that the **EIP** and **EBP** pointers to return to the previos function are **stored in the stack**. Therefore, an attacker will be able to overwrite those and **control the execution flow of the program**.
The main problem of this overwrite is that the **saved instruction pointer (EIP/RIP)** and the **saved base pointer (EBP/RBP)** to return to the previous function are **stored on the stack**. Therefore, an attacker will be able to overwrite those and **control the execution flow of the program**.
The vulnerability usually arises because a function **copies inside the stack more bytes than the amount allocated for it**, therefore being able to overwrite other parts of the stack.\
Some common functions vulnerable to this are: `strcpy`, `strcat`, `sprintf`, `gets`, `fgets`...
Some common functions vulnerable to this are: `strcpy`, `strcat`, `sprintf`, `gets`... Also, functions like `fgets` or `read`, that take a length argument, might be used in a vulnerable way if the specified length is greater than the allocated one.
For example, the following functions could be vulnerable:
@ -36,11 +36,11 @@ void vulnerable() {
### Finding Stack Overflows
The most common way to find stack overflows is to give a very big input of `A`s (e.g. `python3 -c 'print("A"*1000)'`) and expected a `Segmentation Fault` indicating that the **address `0x41414141` was tried to be accessed**.
The most common way to find stack overflows is to give a very big input of `A`s (e.g. `python3 -c 'print("A"*1000)'`) and expect a `Segmentation Fault` indicating that the **address `0x41414141` was tried to be accessed**.
Moreover, once you found that there is Stack Overflow vulnerability you will need to find the offset until it's possible to **overwrite the EIP pointer**, for this it's usually used a **De Bruijn sequence.** Which for a given alphabet of size _k_ and subsequences of length _n_ is a **cyclic sequence in which every possible subsequence of length **_**n**_** appears exactly once** as a contiguous subsequence.
Moreover, once you found that there is Stack Overflow vulnerability you will need to find the offset until it's possible to **overwrite the return address**, for this it's usually used a **De Bruijn sequence.** Which for a given alphabet of size _k_ and subsequences of length _n_ is a **cyclic sequence in which every possible subsequence of length **_**n**_** appears exactly once** as a contiguous subsequence.
This way, instead of needing to figure out which offset is overwriting the EIP by hand, it's possible to use as padding one of these sequences and then find the offset of the bytes that ended overwriting it.
This way, instead of needing to figure out which offset is needed to control the EIP by hand, it's possible to use as padding one of these sequences and then find the offset of the bytes that ended overwriting it.
It's possible to use **pwntools** for this:
@ -67,14 +67,14 @@ pattern search $rsp #Search the offset given the content of $rsp
## Exploiting Stack Overflows
During an overflow (supposing the overflow size if big enough) you will be able to overwrite values of other variables inside the stack until reaching the EBP and EIP (or even more).\
The most common way to abuse this type of vulnerability is by **modifying the EIP pointer** so when the function ends the **control flow will be redirected wherever the user specified** in this pointer.
During an overflow (supposing the overflow size if big enough) you will be able to overwrite values of local variables inside the stack until reaching the saved EBP/RBP and EIP/RIP (or even more).\
The most common way to abuse this type of vulnerability is by **modifying the return address** so when the function ends the **control flow will be redirected wherever the user specified** in this pointer.
However, in other scenarios maybe just **overwriting some variables values in the stack** might be enough for the exploitation (like in easy CTF challenges).
### Ret2win
In this type of CTF challenges, there is a **function** **inside** the binary that is **never called** and that **you need to call in order to win**. For these challenges you just need to find the **offset to overwrite the EIP** and **find the address of the function** to call (usually [**ASLR**](../common-binary-protections-and-bypasses/aslr/) would be disabled) so when the vulnerable function returns, the hidden function will be called:
In this type of CTF challenges, there is a **function** **inside** the binary that is **never called** and that **you need to call in order to win**. For these challenges you just need to find the **offset to overwrite the return address** and **find the address of the function** to call (usually [**ASLR**](../common-binary-protections-and-bypasses/aslr/) would be disabled) so when the vulnerable function returns, the hidden function will be called:
{% content-ref url="ret2win.md" %}
[ret2win.md](ret2win.md)
@ -82,7 +82,7 @@ In this type of CTF challenges, there is a **function** **inside** the binary th
### Stack Shellcode
In this scenario the attacker could place a shellcode in the stack and abuse the controlled EIP to go to the shellcode and execute the attackers code:
In this scenario the attacker could place a shellcode in the stack and abuse the controlled EIP/RIP to jump to the shellcode and execute arbitrary code:
{% content-ref url="stack-shellcode.md" %}
[stack-shellcode.md](stack-shellcode.md)
@ -90,7 +90,7 @@ In this scenario the attacker could place a shellcode in the stack and abuse the
## ROP
This technique is the fundamental framework to bypass the main protection to the previous technique: **No executable stack**. And it allows to perform several other techniques (ret2lib, ret2syscall...) that will end executeing arbitrary commands by abusing existing intructions in the binary:
This technique is the fundamental framework to bypass the main protection to the previous technique: **No executable stack** (NX). And it allows to perform several other techniques (ret2lib, ret2syscall...) that will end executing arbitrary commands by abusing existing intructions in the binary:
{% content-ref url="rop-return-oriented-programing.md" %}
[rop-return-oriented-programing.md](rop-return-oriented-programing.md)