【pwn61.0】Oath to Order – Ricerca CTF 2023

1. イントロ

Hey yo, おれの名前はMC NEET、悪そうなやつはだいたい悪い。

さて、久しぶりにCTFに出たのでCTFの記事を書きます。 まぁ解けなかったので、他の人のwriteupを見て写経です。楽しいね。 題材はRicerca CTF 2023のOath to Order。全然関係ないんですが、ぼくは未だにRicercaのスペルを調べないで書けたことがありません。どう頑張ってもRichelcaって書いちゃう。誰か良い覚え方があったら教えてください。

2. Challenge Analysis

The challenge is a simple note allocator, where

• We can allocate up to NOTE_LEN(== 10) notes, with each note can have up to NOTE_SIZE(== 300) bytes.
• We can NOT free allocated notes.
• We can NOT edit allocated notes.
• We can specify an index of note to write to. We can write to the same note multiple times, but new allocation is performed everytime.
• Allocation is done by aligned_alloc(align, size), where we can specify align smaller than NOTE_SIZE.

The most curious thing is that notes are allocated by aligned_alloc. I will briefly introduce this function later in this post.

3. Vulnerability

Actually, I couldn’t find out the vuln in the program at first glance. So I wrote simple fuzzer and hanged out. When I go back home, the fuzzer crashed when align == 0x100 and size == 0. Okay, this is a vuln:

When size is zero, we can input data of arbitrary size.

4. Understanding aligned_alloc to leak libcbase

aligned_alloc is a function to allocate memory at specified alignment. Below is a simple flow to allocate a memory:

• If align is smaller than MALLOC_ALIGNMENT (==0x10 in many env), just call __libc_malloc(). Note that calling __libc_malloc is a little bit important later.
• If align is not a power of 2, round up to the next power of 2. (I think this violates POSIX standard, but no worry this is glibc)
• Calls __int_memalign(), where __int_malloc() is called for the size of size + align, which is the worst case of an alignment mismatche.
• Find the aligned spot in allocated chunk, and split the chunk into three. The first and the third is freed, then the second is returned.

This is a pretty simplified explanation, but it’s enough to solve this chall.

5. Heap Puzzle: Leak libcbase by freeing alloced fastbin

First, we allocate a chunk with alignment 0xF0 and size 0:

Note that when we call aligned_alloc with size 0, it allocates minimum size of chunk, which is 0x20. Right after the allocation, heap looks as follows:

We overwrote C’s header with prev_size = 0xF0 and size = 0x40. Obviously, prev_size is invalid for now, but becomes valid later.

Then, we allocate chunks in Chunk A:

Heap looks as follows:

Chunk A1 and A2 are allocated from Chunk A. We overwrote A2’s header with size = 0xF0 and prev_in_use set. Now, prev_size of Chunk C became valid, which means that A2+B becomes a valid prev chunk of C.

Finally, we allocate a chunk of size 0xD0, which is allocated from A2+B in unsorted bins:

This is where the magic happens. Heap looks as follows:

Chunk is allocated from unsorted bins and it mistakenly assumes that the size is 0xF0, which We overwrote with. Therefore, Chunk B is freed and connected to fastbin, though it is still in use for notes. We can leak the addr of unsortedbin via fd by reading the note[0]. We got a libcbase.

Overwriting tcache directly for AAW

You may notice that I wrote [!] tcache in the heap layout. tcache is allocated in the middle of chunks in the above layout. This is because tcache is initialized when __libc_malloc is called first time. Remember that we first call aligned_alloc with align = 0xF0 and then with align = 0x0. When we call aligned_alloc with enough align value, it directly calls _int_malloc, which does NOT initialize tcache. This is a good news, because we can easily overwrite tcache in the middle of heap by the overflow.

We set counts of size = 0x20 to 1, and entries of the size to _IO_2_1_stderr_. Yes we have to do FSOP.

6. FSOP: abusing wfile vtable

TBH, i’m totally stranger around FSOP of latest glibc. So I searched for some writeups and found good articles:

• https://blog.kylebot.net/2022/10/22/angry-FSROP/
• https://ctftime.org/writeup/34812
• https://nasm.re/posts/onceforall/
• https://github.com/nobodyisnobody/write-ups/tree/main/Hack.lu.CTF.2022/pwn/byor

Plainly speaking, calls to funcs in vtable _wide_vtable, which is invoked in funcs in _IO_wfile_jumps, are not supervised. So my approach is:

• Target is __IO_2_1_stderr_ (hereinafter called stderr).
• Overwrite stderr._wide_data._wide_vtable to point to somewhere we can write to.
• Overwrite stderr._vtable from _IO_file_jumps to _IO_wfile_jumps.
• Call stderr._vtable.__overflow == _IO_wfile_overflow to invoke call to stderr._wide_data._wide_vtable.__doallocate.

__overflow is called when glibc is exiting. glibc calls _IO_cleanup(), where __IO_flush_all_lockp() is called:

We can read some restriction of stderr from this code to reach _IO_OVERFLOW:

• _mode must be larger than 0
• _wide_data->_IO_write_ptr must be greater than _wide_data->_IO_write_base

Then, _IO_wfile_overflow is called:

Additional restriction of stderr:

• _flags & _IO_NO_WRITES(=0x8) must be 0
• _flags & _IO_CURRENTLY_PUTTING(0x800) must be 0
• _wide_data->_IO_write_base must be NULL

Finally, _IO_wdoallocbuf is called:

Final restriction:

• _flags & _IO_UNBUFFERED(0x2) must be 0

To fulfill all the conditions, we can overwrite stderr and following stdout as below:

We use stdout as a buffer for _wide_data (, and entries of fake vtable). In this challenge, IO is performed by read/write calls. So these FILE structure can be tampered. As a sidenote, stderr is the first entry of the chain of FILE structures, so we have to pay no attention to stdout and stdin at all :). When we call wide_vtable.__doallocate, which is overwritten with system(), RDI is fp, which is stderr in this case. So we wanna place the string /bin/sh\x00 at the start of stderr. However, here is a _flag and it has some restrictions stated above. And the string doesn’t match the condition. No worry. We can just prefix the /bin/sh\x00 with 8 spaces(0x20), then all conditions are fulfilled. Space is a great character for FSOP!

7. Full Exploit

https://github.com/smallkirby/pwn-writeups/blob/master/ricerca2023/oath-to-order/exploit.py

8. アウトロ

いや〜〜、めちゃくちゃパズルで最高ですね。scanf/printfじゃなくてread/writeを使ってたのは、stdoutをぐちゃぐちゃにしてもいいようになのかな。 最近のglibc FSOP周りを全然知らなかったので、とても勉強になりました。これを機にCTF再開しようかなと思えるくらいには楽しかったです。

あと余談なんですが、再来週に人生初飛行機に乗ってイタリアに行かなくちゃいけないので、その前に遺書を書かなくちゃなぁと思っています。

9. Refs

• Shift Crops’ Writeup

原文始发于smallkirby：【pwn61.0】Oath to Order – Ricerca CTF 2023