【保護機構と回避編】Canary・PIE・ASLR・RELROの戦い方｜CTF思考フレームワーク #65

こんにちは、アンペンです！

今回は保護機構と回避編。これまでBoF・ROP・FSB・Heap攻撃と扱ってきましたが、攻撃側の発展に伴いOS・コンパイラ・CPUは多層の保護機構を積み上げてきました。checksec1コマンドで4項目(Canary・NX・PIE/ASLR・RELRO)を確認できる現代では、各保護の『何を守るか』『どう突破されるか』を覚えるのが攻防両面で必須です。

さらにIntel CET(Shadow Stack/IBT)、ARM PAC/MTE、Hardened allocator(Scudo/GWP-ASan)など新世代のHW・OS保護も実用フェーズに入っており、古典攻撃は『そもそも成立しない』未来が見えてきました。

保護機構の話は、つい『専門用語の暗記大会』になりがちですが、見方を変えると面白いんです。攻める側にとっては『どの壁が立っているか』を最初に確認する偵察、守る側にとっては『どの壁を立てるか』の設計図。同じ4項目を、攻守どちらの目でも読める——それがこの回のテーマです。checksec の出力を“作戦ボード”として読めるようになりましょう。

checksecで全部緑なら絶対安全？

絶対ではない。各保護は『リーク→計算→上書き』を1段ずつ重くする壁。Canaryはリーク経路、PIE/ASLRはアドレスリーク、RELRO Fullなら__free_hook等のhookか_IO_FILE系を狙う応用へ。1層ずつ崩していく発想を持とう。

4大保護機構の役割を1枚で把握

• Stack Canary：関数entry時にスタックに『見張り番』値(fs:0x28から読む)を置き、ret前に検証。BoFで戻りアドレスまで上書きするとcanaryもズレるためabortできる。-fstack-protector-strongで有効化
• NX/DEP(W^X)：同じページに書き込み権限と実行権限を同時付与しない。スタック・ヒープ上のshellcode実行を不可能にする
• ASLR/PIE：カーネルが各実行でlibc/コード/スタック/ヒープのベースアドレスをランダム化。アドレス推測攻撃を困難に。PIE(Position Independent Executable)で本体バイナリもランダム化対象に
• RELRO(Partial/Full)：Partialは『起動時にGOTを書込禁止だが遅延解決領域は書込可』、Fullは『起動時に全関数を解決し全GOTを読取専用化』。GOT Overwriteの根を断つ

ここで大事な考え方を一つ。これらの保護は、単体で『絶対に破られない壁』ではありません。それぞれは『攻撃を一段ずつ重くする壁』です。Canaryがあればリークの一手間が増え、ASLRがあればアドレス特定の一手間が増える。一枚一枚は乗り越えられても、重ねるほど攻撃の手数とコストが跳ね上がる。“完璧な壁”ではなく“面倒くささの積み増し”——この発想が、多層防御の本質なんです。

図解：checksecの読み方と各層の突破口

checksec --file=./vulnで一目で確認できる4項目について、『どの状態でどう突破できるか』を頭に入れておくと、CTF問題開いた瞬間に作戦が立ちます。

保護別 定番回避マップ

• Canary回避：FSBやformat string経由でcanary値を盗む→ペイロード内で同値に再現してret書換。マルチスレッドではfork後にcanaryが継承される性質を利用してbrute-force回避もある
• NX回避：shellcode諦め→ROP / ret2libc / ret2csu / SROP(Sigreturn-Oriented Programming)
• ASLR/PIE回避：libc関数アドレスをリーク(puts(puts@got)等)→libc_base = leak - libc.symbols['puts']
• RELRO Full回避：GOT書換は無理→__free_hook/__malloc_hook(glibc < 2.34)、または_IO_2_1_stdout_のvtableを書く
• すべて緑+CET+メモリ安全言語：古典攻撃ほぼ無効。ロジック脆弱性や認証バグなど、別の入り口を探す段階に移行

新世代保護機構：CET・PAC・MTE・Scudo

古典4層を越えるため、現代CPUとモバイルOSは『そもそも攻撃の前提を壊す』ハードウェア保護を装備し始めています。

ここからの新世代保護は、発想がひと味違います。古典4層が『攻撃を難しくする』壁だったのに対し、CETやMTEは『そもそも攻撃の前提を成り立たせない』——たとえば“戻りアドレスは書き換えられて当たり前”という前提を、ハードウェアごとひっくり返してしまうんです。攻撃者が長年使ってきた土台そのものを崩しにかかる、いわば“ちゃぶ台返し”の防御だと言えます。

• Intel CET-Shadow Stack：HW専用の影スタックがcall時にretアドレスを保存、ret時に通常スタックと比較。BoF/ROPで戻りアドレスを書き換えると即CPU例外。Tiger Lake(2020)以降のIntel CPUとWindows 11・Linux 6.x系で実用化
• Intel CET-IBT(Indirect Branch Tracking)：間接call/jmpの先頭にendbr64命令を要求。攻撃者ガジェットの多くはendbr64を持たないため弾かれる
• ARM PAC(Pointer Authentication)：関数ポインタの上位ビットに暗号署名を付与、改ざんを検出。Apple M1/M2やAndroid ARMv8.3+で実装
• ARM MTE(Memory Tagging Extension)：16バイト粒度でメモリにタグを付与、アクセス時にポインタのタグと比較。UAF/Heap-BoFを確率的に検出。Pixel 8+で本番採用
• Hardened allocator：Scudo(Android標準)、GWP-ASan(確率的ASan)、mimalloc-secureでヒープ攻撃を本番環境でも低オーバーヘッドで検出

CTFでやってみよう：checksec読み→突破口決定

守る側：『すべてON + 新世代を順次追加』

『城を1層ずつ崩す』ってイメージで分かりやすいね。

次回はPwn章の総まとめ。実戦シナリオ+チートシートで完走するよ。

まとめ：『1層ずつリークして崩す』

今日の持ち帰りは『保護機構は“偵察対象”であり“設計図”でもある』。攻める人は checksec で立っている壁を見て手数を読み、守る人は全部の壁を立ててCIで退化を見張る。そして時代は、壁を高くする発想から“前提を壊す”新世代保護へ。攻防の最前線がいちばん速く動く、それがこの保護機構の領域です。

次回はPwn章の総まとめ。実戦シナリオとチートシートで全Pwn技術を統合して完走します。

次に読みたい記事

参考資料