Fujisaki久しぶりです。7月一杯はテスト続きで遊べそうにありません...。8月は多少遊べるかと思いますが、9月の初旬にはまたテストがあります。9月の初旬のテストの後はまた一ヶ月ほど休みがあるので、その時には色々出来るかもしれません。あっ、でも免許取らないと。いえ、情報科学概論Iという講義を聴いている最中にふと思いついたセキュリティネタがあったので投稿します。調べた感じだとこの手法は見つからなかったんですが、どう考えてもたいした工夫ではないので既出かもしれません。■攻撃コードlibcに限らず、実行できてはいけない処理が意図しないタイミングで実行されるLinuxではさらに制限が掛かる出来そうな対策は?return-to-libc攻撃とASLRまずreturn-to-libc攻撃について説明しましょう。知ってるという方は飛ばしてください。return-to-libcはバッファオーバーフロー攻撃の一種です。スタック上のバッファに、その大きさ以上のデータを書き込んでしまうことで発生します。イメージとしてはこんな感じ関数がリターンした後のスタックの構造が、ちょうどsytem関数を呼び出したときと同じように工夫するのがミソです。CPUはこの時、system(“cmd”)が実行された時と同じように振る舞い、結果任意のコマンドを実行させる事が可能になってしまいます。Vista以降では、ASLRといって、system()関数も含めた外部ライブラリに含まれる関数のアドレスを毎回ランダムにする事でこの攻撃を防いでいます。戻るべきsystem()関数のアドレスが毎回変わってしまうのですから、攻撃を成功させることも難しくなる、大変有効な対策です。†1アドレスが毎回変わらない関数しかし、毎回アドレスが絶対に変わらない関数があります。それはアプリケーション内の関数です。アプリケーション内の関数は、DLLでロードされるライブラリと違い、毎回ロード先のアドレスが変わらないようです。Starter(32ビット)で確認できた実演デモ本来はファイルの内容を表示するプログラムですが、この脆弱性によってシェルを実行するように改変されています。Starter(どちらも32ビット)で動作を確認しています。Vista(どちらも32ビット)で動作を確認しています。アップーデートで使えなくなる可能性は十分ありますので、起動しなくてもめげないでね!■スクリーンショットこんな感じでシェルが実行されます。■コードの解説まずは意図的にバッファーオーバーフローさせてるプログラムのソースコードを。);//ファイルサイズ分だけコピー。ここでオーバーフロー。0;}上のほうのexec()がポイントです。想定としては、プログラム内から他のアプリケーションを呼ぶような動作を模擬したものと考えてください。message”を表示させることなくsystem関数を呼び出し、さらにそのコマンドも”ipconfig”でなく”cmd”を実行します。....最初の40バイトはバッファにあふれない分のデータです。何かメッセージが出ないと寂しいので、文章を書き込んであります。<JMP.&msvcrt.system>"がおいてあるところへのポインタ関数が戻るまでにクラッシュしないように工夫した†2ローカル変数領域です。リターンアドレスが、exec()内でsystem関数を呼び出す直前になっています。<JMP.&msvcrt.system>”に戻ったときに使うデータです。<JMP.&msvcrt.system>”を実行すればコマンドプロンプトが実行される、というわけです。libcに限らず、実行できてはいけない処理が意図しないタイミングで実行されるこの手法を使えば、プログラム中に含まれるありとあらゆる処理が意図しないタイミングで実行し放題になると思われます。出来そうな事はこんな感じ。今回のように、アプリケーション内で呼ばれているAPI(たとえばsystem())に戻って任意のコマンドを実行するパスワードやらなにやらの認証機構で保護されている処理を無理やり呼び出すWinGrooveのコピートラップ関数を呼び出す(笑)Linuxではさらに制限が掛かるlinuxでは「PAX」によって以下のようにスタックのアドレスも毎回ランダムで変わるので、Windowsより制限が厳しくなります。スタック破壊を検出するStack-Smashing-Protectorとかでも制限が掛かるかも...。bfbc6288このように、毎回かなりランダムになる事が分かります。文字列等のポインタを扱うにはスタック上のアドレスが必要なので使えず、イミディエイトな値のみしか扱えなくなります。いえ、この辺は通常のreturn-to-libcと同じなのでいろいろと回避テクがあるかもしれません。出来そうな対策は?DLLだけでなく、アプリのロード先も毎回ランダムにするこれしかないと思います。今ちょっと確認したところ、殆どのソフトウェア内のcall/jmpはすべて相対ジャンプで行われているようですし、たぶん問題は起きないと思います。DLLでは既にそうなっていますから、特に問題は無いはず...。ちなみに、洞窟物語のパッチがうまくVista以降で動かないのもこれが原因です。コメントをキャンセルメールアドレスが公開されることはありません。※サイトコメントに返信があったらメールで通知する。コメントデータの処理方法の詳細はこちらをご覧ください。