pwn-library

Chunk(addr=0x555555559010, size=0x1240, flags=PREV_INUSE) [0x0000555555559010 78 1b dd f7 ff 7f 00 00 78 1b dd f7 ff 7f 00 00 x.......x.......] Chunk(addr=0x55555555a250, size=0x20, flags=) [0x000055555555a250 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............] 위의 올린 청크 모양에서 borrow_book 을 호출한 뒤 return_book 을 호출하면 해당 책이 있었던 자리 0x555555559010 부분이 UAF 취약점으로 인해 leak 이 된다는 것을 확인 하였습니다. 상단에 있는 0x555555559010 청크 때문에 0x55555555a250 청크를 어떻게 leak 해야하는지 모르겠습니다. - 처음에는 0x555555559010 청크가 unsorted bins 로 가길래 해당 size 만큼 재할당 시켜주면 0x555555559010 청크를 무력화 시킬 수 있다고 생각하였지만 소용이 없었습니다(원하는 만큼의 size 의 재할당이 힘들었습니다) 혹시 실례가 안된다면 힌트좀 부탁드려도 될까요? 수정 문제는 풀었습니다 하지만 tcache 할땐 되고 small bin 안되는지 궁금합니다

275를 입력하면 플래그를 secretbook구조체에 저장할 수 있다는 것 까지는 알 수 있었습니다. 플래그를 얻으려면 bookstruct의 contents필드에 접근해야하고 문제 파일에서 contents를 출력하려면 read_book()함수를 써야합니다. 하지만 이 함수는 listbook내의 원소들만 조회할 수 있도록 만들어졌기 때문에 모종의 방법을 써서 read_book()내의 listbook[select]가 secretbook이 되도록 변조해야 한다고 생각했습니다. 하지만 이 이상은 어떻게 할지 떠오르지 않습니다. 읽을 만한 문서가 혹시 있을까요?

문제는 풀었으나, 서버와 다르게 로컬(ubuntu 16.04, /lib/x86_64-linux-gnu/libc-2.23.so GNU C Library (Ubuntu GLIBC 2.23-0ubuntu11.3) stable release version 2.23, by Roland McGrath et al. Copyright (C) 2016 Free Software Foundation, Inc.) 에서는 flag를 steal 하면 이상한 0x1241 정도의 큰 unsorted bin 청크가 생깁니다. 왜 그러는 지 궁금합니다. 그리고 서버에서도 궁금한 점은 steal 하는 size가 꼭 borrow 된 사이즈에 맞추어야 하는지 의문이 드는데, 같은 주소를 가리키고 있다면, 만약 0x100만큼을 borrow하고 UAF 한다고 할 때 steal을 0x30만큼 하더라도 읽을 수 있는게 아닌가요? 왜 안되는지 모르겠습니다..