hacktricks/binary-exploitation/stack-overflow
2024-04-06 16:25:58 +00:00
..
pointer-redirecting.md GITBOOK-4301: No subject 2024-04-06 16:25:58 +00:00
README.md GITBOOK-4301: No subject 2024-04-06 16:25:58 +00:00
ret2win.md GITBOOK-4301: No subject 2024-04-06 16:25:58 +00:00
stack-pivoting-ebp2ret-ebp-chaining.md GITBOOK-4301: No subject 2024-04-06 16:25:58 +00:00
stack-shellcode.md GITBOOK-4301: No subject 2024-04-06 16:25:58 +00:00
uninitialized-variables.md GITBOOK-4301: No subject 2024-04-06 16:25:58 +00:00

Stack Overflow

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

What is a Stack Overflow

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 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...

For example, the following functions could be vulnerable:

void vulnerable() {
    char buffer[128];
    printf("Enter some text: ");
    gets(buffer); // This is where the vulnerability lies
    printf("You entered: %s\n", buffer);
}

Finding Stack Overflows offsets

The most common way to find stack overflows is to give a very big input of As (e.g. python3 -c 'print("A"*1000)') and expected 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.

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.

It's possible to use pwntools for this:

from pwn import *

# Generate a De Bruijn sequence of length 1000 with an alphabet size of 256 (byte values)
pattern = cyclic(1000)

# This is an example value that you'd have found in the EIP/IP register upon crash
eip_value = p32(0x6161616c)
offset = cyclic_find(eip_value)  # Finds the offset of the sequence in the De Bruijn pattern
print(f"The offset is: {offset}")

or GEF:

#Patterns
pattern create 200 #Generate length 200 pattern
pattern search "avaaawaa" #Search for the offset of that substring
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.

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 would be disabled) so when the vulnerable function returns, the hidden function will be called:

{% content-ref url="ret2win.md" %} ret2win.md {% endcontent-ref %}

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:

{% content-ref url="stack-shellcode.md" %} stack-shellcode.md {% endcontent-ref %}

ROP & Ret2... techniques

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 executing arbitrary commands by abusing existing instructions in the binary:

{% content-ref url="../rop-return-oriented-programing/" %} rop-return-oriented-programing {% endcontent-ref %}

Types of protections

There are several protections trying to prevent the exploitation of vulnerabilities, check them in:

{% content-ref url="../common-binary-protections-and-bypasses/" %} common-binary-protections-and-bypasses {% endcontent-ref %}

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks: