[🥉 Bronze 3] 저장된 EBP 한 바이트를 지워 셸을 연다 — DreamHack off_by_one_000 풀이

문제 개요

풀이 흐름은 짧다. read 로 전역 버퍼를 널 없이 가득 채우고, strcpy 가 그 널 없는 문자열을 스택 버퍼로 옮기면서 딱 한 바이트를 흘린다. 그 한 바이트가 저장된 EBP 의 끝을 0으로 만들고, main 이 돌아나갈 때 그 EBP 로 스택을 되짚으며 우리가 심어둔 주소로 점프한다.

이제 왜 그 한 바이트가 새는지, 그게 왜 하필 EBP 로 떨어지는지, 그리고 왜 항상 성공하지는 않는지를 순서대로 본다.

🧩 배경 — read 와 strcpy 의 널 처리가 다르다

이 문제는 딱 두 함수의 성격 차이 위에 서 있다.

read(0, buf, n) 은 바이트 스트림을 그대로 n 개까지 옮긴다. 문자열 함수가 아니라서 끝에 \0 을 붙이지 않는다. 우리가 256바이트를 보내면 256바이트만 정확히 쓰고 끝이다.

strcpy(dst, src) 는 반대다. src 에서 \0 을 만날 때까지 복사한다. 종단 널까지 같이 써 준다. 그러니 src 안에 널이 없으면, 원래 크기를 넘어 다음 널을 찾을 때까지 계속 긁어온다.

두 성격을 한 흐름에 이어 붙이면 문제가 된다. read 로 널 없이 채운 버퍼를 strcpy 로 옮기면, 복사량이 "내가 넣은 바이트 수 + 그 뒤에서 처음 만나는 널까지" 로 늘어난다.

전역 cp_name 바로 뒤는 초기화된 BSS 라 0이다. 그래서 정확히 256 + 널 1바이트 = 257바이트가 복사된다. 이 1바이트가 이번 문제의 전부다.

한 가지 짚어둘 점. 이 257번째 널이 "터지려면" cp_name 256바이트에 널이 하나도 없어야 한다. 중간에 널이 끼면 strcpy 가 거기서 끊겨 오버플로우가 안 난다. 그래서 페이로드는 널 없는 256바이트여야 한다는 제약이 자연스럽게 따라온다.

🔬 코드 정찰

제공된 소스는 47줄뿐이다. 전부 옮기면 이렇다.

get_shell 이 통째로 있으니 목표는 명확하다. 어떻게든 실행 흐름을 그 주소로 돌리면 된다. 그 주소가 몇 번지인지부터 nm 으로 확인했다.

• get_shell = 0x080485db — 우리가 착지시킬 목표
• cp_name = 0x0804a060 — 전역 BSS 버퍼
• read, strcpy — 위에서 본 그 조합

No PIE 라서 이 주소들은 실행마다 그대로다. get_shell 을 하드코딩할 수 있다는 뜻이다.

문제는 흐름을 어떻게 그리로 보내느냐다. real_name 도 256, read 도 256 이라 평범한 버퍼 오버플로우처럼 리턴 주소까지 덮을 여유가 없다. 넘치는 건 딱 한 바이트다. 그 한 바이트가 정확히 어디로 떨어지는지 보려면 cpy 의 스택 배치를 봐야 한다.

핵심 세 줄만 짚으면 된다.

real_name 이 [ebp-0x100] 에서 시작해 256바이트다. 그러면 real_name[255] 이 [ebp-1] 이고, **real_name[256] 은 정확히 [ebp] — 저장된 EBP 의 첫 바이트(최하위)**다. strcpy 가 흘리는 257번째 널 한 개가 여기로 떨어진다. 리턴 주소([ebp+4])는 손도 못 대지만, 저장된 EBP 는 끝자락이 0으로 지워진다.

그럼 그 지워진 EBP 가 어디서 쓰이길래 흐름을 훔칠 수 있을까. main 쪽 디스어셈블리를 보면 답이 나온다.

main 은 read 로 cp_name 에 0x100(256) 바이트를 받고 cpy 를 부른다. 그리고 마지막에 자기도 leave; ret 로 끝난다. 바로 이 leave; ret 이 무대다. cpy 에서 지운 EBP 가 main 의 프레임 포인터로 흘러들어와, main 이 돌아나갈 때 그 값으로 스택을 되짚기 때문이다.

💣 핵심 — 저장된 EBP 의 LSB 를 지운다

말로만 하면 미덥지 않으니 gdb 로 실제로 밟아봤다. cpy 의 strcpy 직전과 직후, 그리고 main 복귀 시점에 저장된 EBP 값을 찍는 스크립트다.

정확히 예상대로다.

• strcpy 직전: 저장된 main-ebp = 0xffffcbe8
• strcpy 직후: 저장된 main-ebp = 0xffffcb00 — 최하위 바이트 0xe8 이 0x00 으로 지워졌다
• cpy ret 후 main: ebp = 0xffffcb00 — 오염된 값이 그대로 main 의 프레임 포인터가 됐다

여기서부터가 이 문제의 묘미다. cpy 의 leave 는 pop ebp 로 이 오염된 값을 main 의 EBP 에 넣고, ret 은 리턴 주소(멀쩡함)로 main 에 돌아간다. 그런데 main 도 끝에서 leave; ret 을 한다. 이때 main 의 EBP 는 이미 0xffffcb00 으로 오염돼 있다.

leave 가 esp 를 오염된 EBP(0xffffcb00)로 끌어내린다. 원래 EBP 보다 최대 255바이트 아래, 0x100 경계로 정렬된 지점이다. 그리고 ret 이 [esp+4] 를 리턴 주소로 꺼낸다. 그 자리는 방금 우리가 real_name 을 채웠던 스택 영역 안이다.

그래서 페이로드를 get_shell 주소로 256바이트 전부 도배한다. 피벗이 버퍼 안 어디로 떨어지든, 4바이트 정렬만 맞으면 [esp+4] 에서 0x080485db 를 집어 든다. 0x080485db 는 바이트에 널이 없어(db 85 04 08) read·strcpy 어느 쪽에서도 잘리지 않는다.

🎯 익스플로잇 설계

정리하면 조건은 세 가지다.

• 256바이트를 정확히 보낸다 — 덜 보내면 read 가 남긴 이전 널이 섞여 strcpy 가 일찍 끊긴다.

• 그 256바이트에 널이 없어야 한다 — get_shell 주소 반복이 이 조건을 자동으로 만족한다.

• 개행 없이 send 로 보낸다 — sendline 은 \n 을 붙여 257바이트가 되고, 그 \n(0x0a) 이 버퍼를 어긋나게 한다.

한 가지 솔직하게 적어둘 게 있다. 이 기법은 항상 성공하지 않는다.

피벗 지점은 main 의 EBP 하위 바이트에 좌우되는데, 그 값은 스택 ASLR 때문에 실행마다 달라진다. 하필 나쁜 값이면 [esp+4] 가 버퍼 밖이나 엉뚱한 곳을 가리켜 크래시가 난다. 그래서 셸이 뜰 때까지 재시도하는 게 정석이다.

말이 아니라 숫자로 확인하고 싶어서, 로컬에서 같은 페이로드로 30번 돌려 성공/실패를 세어봤다.

O 와 . 가 뒤섞여 나온다. 회차마다 성공률은 출렁이지만(대략 20~50%), 요점은 분명하다. 한 번에 안 되면 다시 붙으면 된다. 원격도 같은 원리라, 셸이 뜰 때까지 새로 연결하면 그만이다.

그전에 로컬에서 재시도 루프로 셸이 실제로 뜨는지부터 확인했다.

7번째 시도에서 /bin/sh 가 열리고 id 가 돌았다. 기법이 맞다는 게 확인됐으니 원격도 같은 방식이다.

🚀 Full Exploit

로컬과 원격을 한 파일로 묶었다. 원격은 연결마다 새로 접속해서, 셸이 열리면 곧장 id 와 cat /flag* 를 흘려보낸다.

이번엔 첫 연결에서 바로 붙었다.

📝 결론

한 바이트의 위치가 전부다.

같은 off-by-one 이라도 넘치는 바이트가 어디로 떨어지느냐에 따라 결과가 완전히 달라진다. 001 에서는 그 바이트가 int age 를 0으로 만들어 분기 하나를 뒤집었고, 000 에서는 저장된 EBP 를 지워 프레임 전체를 옮겼다. 인접한 게 데이터냐 포인터냐의 차이다.

read 와 문자열 함수를 섞지 않는다.

근본 원인은 read 로 채운 비종단 버퍼를 strcpy 에 그대로 넘긴 것이다. read 가 읽은 길이를 기억해 직접 \0 을 붙이거나, 애초에 길이를 강제하는 strncpy 계열을 썼다면 257번째 바이트는 새어나가지 못했다. 문자열 API 는 "널이 반드시 있다"를 전제하는데, read 는 그 전제를 만들어주지 않는다.

버퍼와 저장된 레지스터 사이에 여백을 둔다.

real_name[256] 이 저장된 EBP 에 딱 붙어 있어서 오프셋 계산 없이도 한 바이트가 정확히 프레임 포인터를 때렸다. 스택 카나리가 있었다면 이 사이에 끼어들어 오버플로우를 먼저 잡아냈을 것이다. No canary 라는 한 줄이 그래서 크다.

확률적 익스플로잇도 익스플로잇이다.

"한 방"의 쾌감은 없지만, 성공 확률이 0이 아니면 재시도로 메우면 된다. 오히려 프레임 포인터 하나를 흔들어 흐름을 가져오는 감각 — 리턴 주소를 직접 못 덮어도 우회로가 있다는 것 — 을 익히기엔 딱 좋은 문제였다.