ハッカーが利用する、スタックカナリ＆ASLRリークとは　セキュリティ機能をすり抜ける脆弱性をやさしく解説

ペネトレーションテスト&バグバウンティ

現代のOSやプログラムは、攻撃から自分を守るために「カナリ」や「ランダム化」といった仕組みを使っています。

でも、もしその仕組みの中身がバレてしまったらどうなるでしょうか。

スタックカナリとASLR

スタックカナリとは

スタックカナリ(Stack Canary)は、バッファオーバーフローから関数の戻り先アドレスを守る仕組みです。

関数が呼ばれるとき、戻りアドレスの前に「カナリ値(番人)」を置いて、オーバーフローで壊れてないかチェックします。

攻撃者がこれを「正しく推測」できたら、保護は突破されてしまいます。

ASLRとは

ASLR(アドレス空間配置のランダム化)は、プログラムの実行アドレスを毎回バラバラにして、攻撃者に正しい場所を当てさせない仕組みです。

毎回アドレスが違えば、シェルコードやROPの実行も難しくなります。

なぜ「リーク」が問題なのか

本来は「秘密」のはずのカナリ値やメモリアドレスが何らかの方法で外に漏れると、攻撃者はその情報を使って、本来は防げたはずの攻撃を成功させてしまうことがあります。

これが「リーク(情報漏れ)」の危険性です。

攻撃例

スタックカナリのバイパス

たとえば、次のようなプログラムで入力ミスによりメモリ内容を表示するバグがあるとします：

printf(buf); // フォーマット文字列脆弱性

この時、%pや%xを使ってカナリ値の内容を読み出せば、

次回の攻撃で正しいカナリを上書きして突破できる可能性が生まれます。

ASLRのバイパス

たとえば、次のような情報漏れがあったとします：

printf(“Your buffer is at: %p\n", buffer);

ここで表示されたアドレスから、ライブラリやヒープ、スタックの位置を逆算し、正確なメモリアドレスを使った攻撃(ROPなど)が可能になります。

実際のエクスプロイト手法

・カナリ値リーク ? バッファオーバーフローの成功率アップ。

・ASLRバイパス ? シェルコードのジャンプ先が確定可能に。

・GOT(Global Offset Table)や libc の関数アドレスを利用したリーク? One-Gadget 攻撃に発展。

対策と防御

・カナリ値を標準出力させない。(printf(buf)のようなコードは危険)

・ASLRを無効化しない。(開発時の便利機能で無効にしたまま公開しない)

・RELRO(Read-Only Relocations)などと併用する。

・セキュアな入力検証を徹底する。