simplelist

SECCON Beginners CTF 2022の問題

t6o_o6t.icon

code:file

./chall: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildIDsha1=c1ea22cea66863313f8fa1c228051f7d991d4dcb, for GNU/Linux 3.2.0, not stripped

checksec

code:checksec

Canary : ✓

NX : ✓

PIE : ✘

Fortify : ✘

RelRO : ✘

PIEではないので、正規の命令のアドレスは固定

RelROは設定されていないので、GOT Overwriteが可能

ソースコードを見た限りでは、gets関数を使っているのが気になる

ヒープオーバーフローを起こすことができるのではないか

今回の条件では、ヒープの各Allocated Chunkは空間的に連続している可能性がある。ゆえに、あるMemoへの入力でオーバーフローを起こせば、それ以降のMemoの値にも影響を与えることができそうだ

ゴールはどこにある？

フラグを表示するような関数はコードに含まれていない。

system() のような関数の呼び出しはないので、GOT Overwriteの効果を得ることは難しい（？）

これは誤りである。system関数そのものは、libcのロード時にメモリに読み込まれている。

libcのベースアドレスが分かれば、libc.so.6上でのsystem関数の位置とベースアドレスを足し合わせ、system関数の位置を特定することが可能だ。

one_gadgetに飛ばすことはできないか？

libcのベースアドレスのリーク

あるMemoのnextを、GOTエントリに向けると、3. Show memoで解決済のアドレスを取得することができるはずだ

たとえば、GOTエントリ0x400008に0x7fff...0a0が入っている状況を考える。

あるMemoのnextを0x400000に上書きすると、その次のMemoをshowするとき、アドレス0x400000がMemo構造体のポインタとして解釈される。

そのため、0x400008がcontentとして表示されるはずだ。

これにより、解決済のアドレスが表示される。

これにより得たアドレスから、libc.so.6におけるその関数のアドレスを引き去ることで、libcのベースアドレスを計算することができる。

GOT overwriteによるシェルの奪取

licbcが

感想

nextを書き換えると、不正に任意のアドレスのメモリ状態を出力することができそう