ImaginaryCTF 2025 stillerer-printf (魔女のお茶会 #8)

Transcript

1. ImaginaryCTF 2025 stillerer-printf 魔女のお茶会 #8(2025 夏) Riru Oda (@ri5255) 1
2. 自己紹介 2 • 学部4年のlow-level programmer • セキュリティ・キャンプ’22-25 • CTF (pwn) • 最近はunsafe RustのBug findingに興味あり Riru Oda (@ri5255)
3. ※ Format String Attackの知識を仮定します 3 ImaginaryCTF 2025: https://2025.imaginaryctf.org/
4. 解析: セキュリティ機構 4
5. 解析: セキュリティ機構 5 • Full RELROなのでGOT overwriteは無理そう
6. 解析: セキュリティ機構 6 • Full RELROなのでGOT overwriteは無理そう • SSP無効なのでstack overflow?
7. 解析: セキュリティ機構 7 • Full RELROなのでGOT overwriteは無理そう • SSP無効なのでstack overflow? • PIE有効なのでaddress leakが必要そう
8. 解析: vuln.c 任意のpwn問はソースコードを配布すべき (※個人の意見です) 8
9. 解析: vuln.c • win関数がある (win関数に飛ばせばいいのかな?) 9
10. 解析: vuln.c • win関数がある (win関数に飛ばせばいいのかな?) • サイズチェックがある(えらい)ので、Buffer Overflowはない 10
11. 解析: vuln.c • win関数がある (win関数に飛ばせばいいのかな?) • サイズチェックがある(えらい)ので、Buffer Overflowはない • 自明なFormat String Bugがある (簡単そう) 11
12. 解析: vuln.c • win関数がある (win関数に飛ばせばいいのかな?) • サイズチェックがある(えらい)ので、Buffer Overflowはない • 自明なFormat String Bugがある (簡単そう) • printf(buf)の後にすぐexitする • _exit関数なので__run_exit_handlersの処理は使えない 12
13. 解析: run.py 13
14. 解析: run.py • 長さとpayloadを受け取る 14
15. 解析: run.py • 長さとpayloadを受け取る • asciiしか使えない (アドレス指定できない ) 15
16. 解析: run.py • 長さとpayloadを受け取る • asciiしか使えない (アドレス指定できない ) • secret.txtにtokenを書き込む 16
17. 解析: run.py • 長さとpayloadを受け取る • asciiしか使えない (アドレス指定できない ) • secret.txtにtokenを書き込む • vulnを実行 (出力は見れない ) 17
18. 解析: run.py • 長さとpayloadを受け取る • asciiしか使えない (アドレス指定できない ) • secret.txtにtokenを書き込む • vulnを実行 (出力は見れない ) • win.txtがsecret.txtと同じなら1 (win関数を実行していれば1になる) 18
19. 解析: run.py • 長さとpayloadを受け取る • asciiしか使えない (アドレス指定できない ) • secret.txtにtokenを書き込む • vulnを実行 (出力は見れない ) • win.txtがsecret.txtと同じなら1 (win関数を実行していれば1になる) • 200回実行して条件を満たせばflagを出力 (196回以上(98%)成功しないとだめ ) 19
20. 解析結果まとめ Ascii文字だけで leaklessかつ 高確率(98%以上)で win関数を実行するformat stringが必要 20
21. 方針 以下は使えない 21
22. 方針 以下は使えない • GOT Overwrite 22
23. 方針 以下は使えない • GOT Overwrite • __run_exit_handlers 23
24. 方針 以下は使えない • GOT Overwrite • __run_exit_handlers printfのリターンアドレスを書き換えるしかない 24
25. 解法 25
26. 解法 26 • %nでpartial overwriteできる
27. 解法 27 • %nでpartial overwriteできる • 下位2byteを書き換えればいい!
28. ところで… 28
29. ところで… 29 • ASLRが有効なのでスタックのベースアドレスは実行ごとに変わる
30. ところで… 30 • ASLRが有効なのでスタックのベースアドレスは実行ごとに変わる • 196/200以上成功する必要があるので、確率的な手法は使えない
31. ところで… 31 • ASLRが有効なのでスタックのベースアドレスは実行ごとに変わる • 196/200以上成功する必要があるので、確率的な手法は使えない stackのアドレスがleakできれば…
32. ところで… 32 • ASLRが有効なのでスタックのベースアドレスは実行ごとに変わる • 196/200以上成功する必要があるので、確率的な手法は使えない • leakできない stackのアドレスがleakできれば…
33. ところで… 33 • ASLRが有効なのでスタックのベースアドレスは実行ごとに変わる • 196/200以上成功する必要があるので、確率的な手法は使えない • leakできない • 複数回printf呼べない
34. アイデア 34 • リターンアドレスが置かれる(スタックの)アドレスを%nで作りたい
35. アイデア 35 • リターンアドレスが置かれる(スタックの)アドレスを%nで作りたい • %nで書き込まれるのは今まで出力したバイト数
36. アイデア 36 • リターンアドレスが置かれる(スタックの)アドレスを%nで作りたい • %nで書き込まれるのは今まで出力したバイト数 • 出力したバイト数にスタックのアドレスの情報を反映させたい
37. アイデア 37 • リターンアドレスが置かれる(スタックの)アドレスを%nで作りたい • %nで書き込まれるのは今まで出力したバイト数 • 出力したバイト数にスタックのアドレスの情報を反映させたい %*c
38. 解法 38 • %*cで出力幅にスタックのアドレス下位4byteを指定できる!
39. 解法 39 • %*cで出力幅にスタックのアドレス下位4byteを指定できる! • ASLR有効でも、offsetは一定なので目的のアドレスが作れる!!
40. 解法 40 • %hnでリターンアドレスが置かれるアドレスを作れた
41. 解法 41 • %hnでリターンアドレスが置かれるアドレスを作れた • あとはwin関数のアドレスに書き換えるだけ!
42. 解法 42 • %hnでリターンアドレスが置かれるアドレスを作れた • あとはwin関数のアドレスに書き換えるだけ! • しかも、リターンアドレスとwin関数の違いは最下位byteだけ!!
43. ところで… 43
44. ところで… 44 • この時点で出力したバイト数の下位1byteはリターンアドレスが 置かれるアドレスの下位1byteに一致する
45. ところで… 45 • この時点で出力したバイト数の下位1byteはリターンアドレスが 置かれるアドレスの下位1byteに一致する • ただ、ASLRが有効なので、この値が分からない
46. ところで… 46 • この時点で出力したバイト数の下位1byteはリターンアドレスが 置かれるアドレスの下位1byteに一致する • ただ、ASLRが有効なので、この値が分からない • どうやって0x09を作る?
47. アイデア • call命令実行時に$rspは必ず16-byte alignされている 47
48. アイデア • call命令実行時に$rspは必ず16-byte alignされている • だからリターンアドレスが置かれるアドレスは必ず8の倍数 (0x?8) 48
49. アイデア • call命令実行時に$rspは必ず16-byte alignされている • だからリターンアドレスが置かれるアドレスは必ず8の倍数 (0x?8) • 0x?8から0x09を作るのがゴール (?が0なら、0x1を足せばいいが..) 49
50. アイデア • call命令実行時に$rspは必ず16-byte alignされている • だからリターンアドレスが置かれるアドレスは必ず8の倍数 (0x?8) • 0x?8から0x09を作るのがゴール (?が0なら、0x1を足せばいいが..) • ?の値を仮定する確率的な手法は使えない 50
51. アイデア • call命令実行時に$rspは必ず16byte-alignされている • だからリターンアドレスが置かれるアドレスは必ず8の倍数 (0x?8) • 0x?8から0x09を作るのがゴール (?が0なら、0x1を足せばいいが..) • ?の値を仮定する確率的な手法は使えない 51 16倍する
52. 解法 • 16倍は4bit左シフトと等価であることと、分配法則より: 52
53. 解法 • 16倍は4bit左シフトと等価であることと、分配法則より: 0x?8 * 16 = (0x?0 + 0x08) * 16 53
54. 解法 • 16倍は4bit左シフトと等価であることと、分配法則より: 0x?8 * 16 = (0x?0 + 0x08) * 16 = 0x?0 * 16 + 0x08 * 16 54
55. 解法 • 16倍は4bit左シフトと等価であることと、分配法則より: 0x?8 * 16 = (0x?0 + 0x08) * 16 = 0x?0 * 16 + 0x08 * 16 = 0x?00 + 0x80 55
56. 解法 • 16倍は4bit左シフトと等価であることと、分配法則より: 0x?8 * 16 = (0x?0 + 0x08) * 16 = 0x?0 * 16 + 0x08 * 16 = 0x?00 + 0x80 = 0x?80 56
57. 解法 • 16倍は4bit左シフトと等価であることと、分配法則より: 0x?8 * 16 = (0x?0 + 0x08) * 16 = 0x?0 * 16 + 0x08 * 16 = 0x?00 + 0x80 = 0x?80 57 • 16倍すれば必ず0x80になるので、0x89を足せば0x09が作れる!
58. 解法 58 • 出力したバイト数の最下位byteを%hhnで書き込む
59. 解法 59 • 出力したバイト数の最下位byteを%hhnで書き込む • %*97$cを15回使って書き込まれた値(0x?8)を16倍
60. 解法 60 • 出力したバイト数の最下位byteを%hhnで書き込む • %*97$cを15回使って書き込まれた値(0x?8)を16倍 • %137cで0x89を足して、0x09を作る
61. 解法 61 • 出力したバイト数の最下位byteを%hhnで書き込む • %*97$cを15回使って書き込まれた値(0x?8)を16倍 • %137cで0x89を足して、0x09を作る • %106$hhnでリターンアドレスを書き換えてret2win
62. 解法 62 最終的なpayload : %c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c %c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c %c%c%c%c%c%c%c%c%c%c%64914c%*c%c%c%c%c%c%c%c%c%c%c %hn%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%hhn%*97$c%*97$ c%*97$c%*97$c%*97$c%*97$c%*97$c%*97$c%*97$c%*97$c% *97$c%*97$c%*97$c%*97$c%*97$c%137c%106$hhn https://github.com/r1ru/pwn-writeups/blob/main/2025/imaginary-ctf/stillerer-printf/exploit.py
63. 解法 63 なぜ2回失敗するのかは謎 (分かる人教えてください)
64. まとめ Ascii文字だけで leaklessかつ 高確率(98%以上)で win関数を実行するformat stringは書ける! 64 今まで解いてきたCTFの中で最高難易度のformat string attackでした… 他にも面白いpwn問題があったのでぜひupsolveしてみてください! (2025/09/23 11:00(JST)時点ではまだサーバーは動いている)
65. 宣伝 • pwnの入門記事を執筆中 • 初歩から丁寧に解説している • Intel CET等の最新のmitigation, heap exploitについても扱う予定 65 https://r1ru.github.io/categories/binary-exploitation-101/
66. 細かい補足 66 • Q: p.33とp.34でindex 0x38の値がしれっと変わっているのはなぜ? (0xffffea80→0x00ffea80) • A: 出力幅に負の値を指定すると、-フラグと幅として解釈されるのでうまくいかない: A negative field width is taken as a ‘-’ flag followed by a positive field width. (https://man7.org/linux/man-pages/man3/printf.3.html) そこで、run.pyのbugを使って、最上位byteを00にしている。(負の値にならないことを祈ることもできるが、 98%成功する必要があるので厳しい。仮に負の値にならなくても、幅として大きな値が指定され、今回出力 はstdoutに書かれる(/dev/nullじゃない)ので、タイムアウトする可能性が高い) Bug: len(payload)==lengthであることは保証されない
67. 細かい補足 67 • Q: ASLRで変わるのはベースアドレスだけで、かつベースアドレスはpage size alignなんだから、リターン アドレスが置かれるアドレスの下位3nibbleは常に固定なのでは? • A: arch_align_stack関数がランダムな値を引くので固定にならない https://elixir.bootlin.com/linux/v6.16.8/source/arch/x86/kernel/process.c#L1013-L1018
68. 細かい補足 68 • Q: %hnでリターンアドレスが置かれるアドレスを作るときに、%Nc%M$hhnのようにしないのはなぜ? %c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c %c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%64914c%*c%c%c%c%c%c%c%c %c%c%c%hn%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%hhn%*97$c%*97$c%*97$c%*97$c%*9 7$c%*97$c%*97$c%*97$c%*97$c%*97$c%*97$c%*97$c%*97$c%*97$c%*97$c%137c%106 $hhn • A: Xprintf_buffer関数は、$を見た瞬間にprintf_positional関数に切り替えて処理をする。 この関数はすべての引数をcopyしてから処理するので、partial overwriteで作ったアドレスを参照 することができない。そのため、%cを繰り返して調整している https://elixir.bootlin.com/glibc/glibc-2.37/source/stdio-common/vfprintf-internal.c#L990-L1340