Writeup - From Format String to Buffer Overflow
First of all we see the protections of the binary.
We have several problems. We can not execute code in the stack such as a shellcode due to NX, we can not overflow without having a canary leak and if we want to attach with gdb we have to bypass PIE as if we want to do ROP (Return-Oriented Programming). We also need leak of a function to be able to make the corresponding calculation of the base memory address of libc for the ROP. Taking a look at the pseudocode generated by Ghidra, we see the first vulnerability a format string, cool!.
We test the software and observe how we can leak the stack with format %x. Therefore we already have how to perform canary leak and bypass PIE. We must check another thing before continuing and that is that the binary is dynamically linked so we will have to leak the address of a function to later know the base memory address of libc.
In order to make the different leak we have to study the stack and see if it meets the requirements we need. If we do AAAA.%x.%x.%x.%x.%x.%x.% x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x.%x there is our output:
So we have our 0x414141 in eighth argument. So we can use this AAAA.%8$x to leak our A's.
We start first with the canary so we execute with GDB until after the printf function call. Canary value is in stack at rbp-0x8 and if we check the stack there will be our thirteen argument: %13$p.
Leak .text memory address to perform PIE bypass protection
With fourteen argument: %14$p we can leak .text to be able to calculate the base address of the binary elf and then bypass PIE. It is very useful to do PIE bypass since it will also allow us to attach to gdb in order to efficiently make the exploit.
Leak memory address of function to perform leak of base libc
With third argument: %3$p we can leak memory address of write function + 20.
We can write our script to perform the corresponding leak remaining as follows:
Libc base address and elf base address
To calculate the base address of libc we must subtract the address of write-20 leaked before minus the offset of write libc. To know the base memory address of the elf binary we must put the last 3 bytes of the leak to zeros using the operation AND with the 0xfff mask.
Then we see that after the scanf function call to know our feedback we have a buffer overflow discovered after a few attempts and step on the value of canary giving us a stack smashing. There is a space between our feedback input to the canary of 24 bytes then 8 bytes for saved rbp and return address.
Exploit with ROP:
It also mentions that PIE leaker is not necessary, with leaking a LIBC address.
Then I'll show you the exploit of my friend @alextaito99 and thanks for doing the challenge together:
Write-up 감사해요! 알아듣기 쉽게 설명해주셨어요. 질문이 몇가지 있는데..
1. 카나리의 널바이트를 덮어씌우는데 아무 문제도 안되나요?
2. elf base 주소는 gdb를 어태치할때 사용하신다고 하였는데 pop rdi의 가젯을 쓸 때도 사용하셨잖아요, 가젯은 그냥 libc에서 찾아 사용해도 되나요? 사실 elf base를 어떻게 사용하신건지 이해가 잘 되지 않아서요. (그리고,, 가젯은 어떻게 찾으셨나요?)
앞으로도 다른 라잇업들 잘 읽을게요! 2019.03.16 05:36
naivenom@debian ~ % theFaunia in the wild
1. If you overwrite canary value with junk data you get smashing stack, so you need to leak it.
2. Because we can leak the base address of elf we can bypass the PIE protection and thus attach the debugger. In the same way we can find gadget of the binary elf or libc as you want. I used ROPgadget.
I will write more writeup from pwnable.kr, pwnable.tw and from other CTF!
Regards 2019.03.18 14:56 신고
- return oriented programming
- hijacking redirection flow
- write primitive
- buffer overflow
- stack pivot
- one gadget
- format string
- fake stack frame
- GOT Dereferencing/Overwriting
- html injection
- use after free
- leak stack memory address
- leak libc
- arithmetic overflow/underflow
- Call oriented programming
- theFaunia course