[🥈 Silver 4] 72바이트로 canary 넘어 리크, free_hook 하이재킹으로 쉘 — DreamHack fho 풀이

이 문제 이름 fho가 가리키는 게 바로 이 Free Hook Overwrite 계열 기법이다. 소스를 보면 그 재료가 이미 다 준비돼 있다.

세 단계가 그대로 프리미티브 세 개다.

1. buf[0x30]에 read(0, buf, 0x100) — 버퍼는 48바이트인데 최대 256바이트를 받으니 스택 오버플로.
2. *addr = value — 주소·값 모두 우리가 정하는 임의주소 1회 write.
3. free(addr) — 우리가 정한 임의 주소를 그대로 free에 넘기는 임의주소 free.

__free_hook에 system을 심고 free("/bin/sh")를 부르면 system("/bin/sh")가 되는 건 이미 잘 알려진 체인이다. 문제는 libc 베이스를 어떻게 아느냐다 — 그리고 그 답이 1번 프리미티브에 숨어 있다.

🔬 코드 정찰

바이너리부터 훑는다.

Full RELRO라 GOT를 덮는 루트는 막혀 있다. Canary도 있으니 순진하게 return address를 덮는 것도 안 된다. 그런데 이 두 보호 기법 다 "애초에 스택을 안 건드리는" 임의주소 write/free 앞에서는 의미가 없다. 필요한 건 하나, libc 주소를 아는 것뿐이다.

💣 핵심 — 72바이트로 canary를 넘고 retaddr은 남긴다

main의 스택 프레임을 objdump로 짚어본다.

lea rax,[rbp-0x40]가 buf의 시작이고, 프롤로그의 mov QWORD PTR [rbp-0x8],rax가 canary 슬롯이다. 즉:

• buf = rbp-0x40
• canary = rbp-0x8 → buf 기준 +56
• saved rbp = rbp+0x0 → buf 기준 +64
• return address = rbp+0x8 → buf 기준 +72

read(0, buf, 0x100)는 최대 256바이트를 받지만, 우리가 실제로 보내는 바이트 수만큼만 덮인다. 정확히 72바이트를 보내면 buf+canary+saved rbp까지만 채워지고 return address는 원래 값 그대로 남는다. 그 상태에서 바로 다음 줄의 printf("Buf: %s\n", buf)가 buf를 문자열로 찍는데, %s는 처음 만나는 0x00에서 멈춘다.

canary의 최하위 바이트는 스택 보호 설계상 항상 0x00이다(문자열 함수로 카나리 자체가 새지 못하게 하려는 장치). 우리가 canary·saved rbp 자리를 non-null 바이트로 덮어버리면, %s는 그 두 구간을 그대로 통과해 이어지는 return address로 들어간다. return address는 우리가 안 건드렸으니 원래 값 그대로고, 그 값의 상위 2바이트는 커널 주소 규칙상 항상 0x0000이라 6바이트를 흘린 다음 거기서 멈춘다. 결과: retaddr 하위 6바이트가 그대로 응답에 찍힌다.

main은 __libc_start_main에서 call rax로 호출되므로, 이 return address는 libc 안의 고정 오프셋이다. libc-2.27.so를 까 보면 그 지점을 바로 찾을 수 있다.

call rax(0x21bf5) 바로 다음 명령 주소 0x21bf7이 main() 호출이 리턴하는 자리다. 즉 libc_base = leak - 0x21bf7.

이 오프셋이 실제 실행 중에도 맞는지 gdb로 한 번 더 확인했다. read() 직후, printf("%s",buf) 호출 직전에 브레이크를 걸고 canary·saved rbp·retaddr 주소와 내용을 직접 찍었다.

로컬 시스템 glibc(2.42, 이 캡쳐용 검증 환경 — 실제 배포 서버의 2.27과는 다른 빌드)라 심볼 이름은 __libc_start_call_main+117로 나오지만, 확인하려던 세 가지는 정확히 들어맞는다: 오프셋 56/64/72, canary 최하위 바이트가 0x00이라는 점, 그리고 retaddr이 항상 libc 안의 고정 함수로 resolve된다는 점. 정확한 심볼 이름과 오프셋은 glibc 빌드마다 다르지만 leak 메커니즘 자체는 동일하다 — 실제 익스플로잇에서 쓰는 0x21bf7은 문제가 제공한 libc-2.27.so 기준이다.

🎯 익스플로잇 — free_hook 하이재킹

libc 베이스를 구하면 나머지는 심볼 오프셋 조회다.

• __free_hook = libc_base + 0x3ed8e8
• system = libc_base + 0x4f550
• "/bin/sh" = libc_base + 0x1b3e1a

체인은 이렇다.

glibc 2.27의 _int_free는 실제로 청크를 만지기 전에 __free_hook이 설정돼 있으면 (*__free_hook)(mem, caller)를 그대로 호출한다. 여기서 mem은 우리가 free()에 넘긴 포인터 그 자체다. __free_hook을 system으로 바꿔두면 mem이 곧 system의 첫 인자가 되므로, free(&"/bin/sh")가 system("/bin/sh")와 같아진다.

로컬 사전검증 — leak 공식이 실제로 맞는지

실서버를 매번 두드리기 전에, 로컬에서 leak 계산이 /proc/[pid]/maps가 말하는 진짜 libc 베이스와 일치하는지부터 확인했다. pwntools의 p.libc.address를 정답지로 두고 우리 leak 공식으로 복원한 값을 대조하는 스크립트다.

leak으로 복원한 주소에서 페이지 오프셋(0x2a575)을 빼면 /proc/maps가 말하는 실제 libc 베이스와 정확히 맞아떨어진다 — 위 gdb 캡쳐에서 본 __libc_start_call_main+117과도 같은 오프셋이다. 리크 공식 자체는 검증됐다.

다만 이 로컬 스크립트는 그 뒤 __free_hook write에서 SIGABRT로 죽는다. 이 시스템의 glibc(2.35+)는 hook 메커니즘 자체를 들어냈기 때문에 — 심볼은 ABI 호환으로 남아있지만 free()가 더는 그 값을 확인하지 않는다 — 우리가 쓴 값은 무시되고 free()가 진짜로 그 "포인터"를 청크로 취급하려다 힙 무결성 검사에 걸려 죽는다. fho가 정확히 glibc 2.27을 못박아 배포하는 이유가 이거다. leak 메커니즘은 리크 대상 코드 자체가 항상 실행되니 glibc 버전과 무관하게 통하지만, hook 하이재킹은 2.33 이하에서만 산다.

🚀 Full Exploit

실제 배포 서버(libc-2.27.so)를 대상으로 한 최종 스크립트다.

실행하면 매번 ASLR로 libc 베이스가 바뀌는데도 leak 공식이 그대로 맞아 들어가고, 곧바로 플래그가 떨어진다.

✅ 제출 확인

자동화 도구(dreamhack.py)로 플래그를 제출해 정답 처리와 VM 크레딧 환급까지 확인했다. (드림핵은 플래그 제출 직후 한 번씩 일시적으로 "오답"으로 잘못 표시했다가 재제출하면 바로 "정답"이 뜨는 경우가 종종 있는데, 이번에도 그랬다 — 실제 채점은 서버 쪽에서 이미 정답으로 기록돼 있었다.)

📝 정리

임의주소 write와 임의주소 free는 그 자체로 이미 끝난 게임이다.

이 문제는 스택 오버플로가 메인이 아니다. 오히려 오버플로는 리크용 조연이고, *addr = value와 free(addr)를 사용자 입력으로 그대로 노출한 두 줄이 진짜 취약점이다. Full RELRO도 canary도 GOT와 리턴 주소를 지킬 뿐, 프로그램이 스스로 내어준 "아무 주소에나 쓰고 아무 주소나 free하는" 기능 앞에서는 할 수 있는 게 없다.

canary의 null 바이트 설계는 완벽하지 않다.

canary 최하위 바이트를 0x00으로 고정해두는 건 문자열 함수로 canary가 새는 걸 막기 위한 장치인데, 그 앞뒤로 우리가 다른 non-null 바이트를 채워 넣을 수 있으면 %s의 정지 지점 자체를 뒤로 밀어버릴 수 있다. 이번처럼 canary 검증이 함수 맨 끝에서만 일어나고 그 전에 다른 임의 프리미티브로 흐름을 가로챌 수 있다면, canary를 건드려도 아무 페널티가 없다.

malloc hook은 이래서 없어졌다.

__free_hook/__malloc_hook처럼 사용자가 함부로 덮을 수 있는 함수 포인터를 힙 구현 안에 남겨두면, 임의주소 write 단 한 번이 곧바로 임의 코드 실행으로 이어진다. glibc 2.34에서 이 훅들을 완전히 제거한 이유가 정확히 이 문제가 보여주는 체인이다.