近来雨后春笋般冒出的琐事逐渐成为了逃避写blog的借口,或者说搜肠刮肚也找不出几行有价值的文字。
上月看的几部作品除了托尼史塔克的”Love you 3000”以外都记不太清了,应该说在情怀面前其他情节都变成了细枝末节。
以后个人blog上的Writeup尽量都用英文写了,看多了各种日文韩文的资料以后,换位思考一下感觉国际化还是有必要的。
This is a challenage from *CTF 2019 last weekend, a great CTF from sixstar team. For this particular challenge, you could found at least 3 avaliable Writeup (except for this one). The official Writeup here, one from shift-crops, and one from the Balsn Team.
I analyzed all three writeups and personally appreciated the one from Japanese player shift-crops the best. So the following paragraphs will focus on his method and try to clarify some glibc heap attack concepts he used.
The official Writeup and shift-crops’ did a great explanation about reversing process, so I’ll spare that part here. The exploit relays heavily on unsorted bin attack, and here is a brief description of this technique.
Unsorted bin Attack
1 | // [PRE-CONDITION] |
Graph
1 | UNSORTED_BIN_LIST HEAP |
With unsorted bin attack, one can write a pointer 0x7ffff7dd1b58 (main_arena+88) to arbitrary address. In this challenge, we cannot write anything on heap directly, and we don’t have any provided function to leak addresses, the very first step is utilizing unsorted bin attack to overwrite something around main_arena.
Exploit
I copied the exploit from shift-crops, refactored it a bit and added some comments, seperating the whole exploit into 6 parts.
1 | from pwn import * |
Investigation
After trying the exploit, Some questions poped up in my head:
- Why do we need to change
global_fast_maxbeforeunsorted bin attack? - Why overwritting
_IO_2_1_stdout_->read_endand_IO_2_1_STDOUT->write_basecan leak so many addresses? - How does
_IO_flush_all_lockpwork?
Q1
To answer this question, I eliminated Part1 in exp, and tried to perform consecutive unsorted bin attack, with following script:
1 | ## PART2: overwrite _IO_2_1_stdout_->_IO_read_end to main_arena+88 |
it thown an memory corruption like:
1 | *** Error in `./heap_master1': malloc(): memory corruption: 0x00007ffff7dd2610 *** |
The arena looks like:
1 | pwndbg> arena |
Traced down the source code of malloc, the error thrown at malloc.c:3405 (version: glibc 2.24)
1 | //malloc.c:3504 |
if we print the varibale victim, it is 0x7ffff7dd2600, which means unsorted_chunks(av)->bk will extract the value of bins[1] here, for sure this address could not pass the check.
The workaround is use fastbin-freeing mechanism to help us fix arena. The source is located at malloc.c:2982
1 | // malloc.c:2982 |
With global_max_fast overwritten with a large value, fake chunk will be treated as a fastbin chunk, this line of code help us to write bin[1] to fake chunk address. BTW, I patched the string /dev/urandom to ./test in prog_init, so for each run we can have the same mmap address. After fixing bin[1], we can perform unsorted bin attack on the same fake chunk again.
1 | pwndbg> arena |
As a conclusion, if you somehow want to perform unsorted bin attack on same chunk many times, you should first use unsorted bin attack to overwrite global_max_fast, and then free the fake chunk as a fastbin chunk to fix arena before each unsorted bin attack.
Q2
When printf is called, it eventually call _IO_file_xsputs and then new_do_write.
1 | //fileops.c:526 |
When we overwrite _IO_2_1_stdout_->read_end==_IO_2_1_stdout==main_arena+88, it hit line 22, which is the exact line to dump stuff to stdout, data is main_arena+88 here and to_do is 0xb2b. Since there are plenty of juicy addresses around main_arena, so with this leak, we can defeat ASLR and even get stack address.
Q3
Angleboy first introduce _IO_flush_all_lockp hijacking in his blog, and here is another post about bypassing the check since 2.24.
Conclusion
I used to consider unsorted bin attack as kind of weak attack primitive, but it turns out to be super powerful with fsop technique. This challenage is a good example about using multiple unsorted bin attack to perform fsop and hijack control flow.
Reference
- https://github.com/sixstars/starctf2019/tree/master/pwn-heap_master
- http://shift-crops.hatenablog.com/entry/2019/04/30/131154#hack_me-Pwn-625pt-13-solves
- https://balsn.tw/ctf_writeup/20190427-\*ctf/#heap-master
- https://dangokyo.me/2018/01/20/extra-exploitation-technique-1-_dl_open/
- http://4ngelboy.blogspot.com/2016/10/hitcon-ctf-qual-2016-house-of-orange.html
- https://xz.aliyun.com/t/2411