情報処理安全確保支援士 2018年 春期 午後1 問01

　 　V社は、従業員数100名のソフトウェア開発会社である。V社では、開発に関わる全員が情報セキュリティを意識した実装を行えるよう、開発経験が浅い従業員にセキュリティ教育を行っている。次は、任意の攻撃コードが実行され得る脆弱性について、開発チームのT主任が部下のUさんに教えていた時の会話である。 　 　T主任：任意の攻撃コードが実行され得る脆弱性は幾つかある。確保済みメモリ領域を超えてデータを書き込んでしまうaと呼ばれる脆弱性の報告が以前から多かった。最近は解放したメモリ領域を後から使用してしまうbと呼ばれる脆弱性の報告も多くなってきている。 　Uさん：bという脆弱性は具体的にはどのようなものなのですか。 　T主任：例えば、図1のC++ソースコードからなるプログラム（以下、例示プログラムという）があったとする。例示プログラムは、図2に示すシステム構成の中で動作し、ノートと呼ぶメモ書き機能を実現するものであり、クライアントから利用者が自身の名前とメッセージを登録したり、それを他の利用者が参照したりする。例示プログラムでは、ノートはNote構造体で表現され、利用者の操作に応じて、NoteManagerクラスの各メンバ関数が個別に呼び出される。各メンバ関数では、ノートの生成（CreateNote）、利用者の名前の登録（RegisterName）、メッセージの登録（RegisterMsg）、ノートの登録内容表示（DisplayNote）、ノートの破棄（DeleteNote）を行う機能を実装している。例示プログラムにおいて、DeleteNoteメンバ関数内でm_noteの指すメモリ領域を解放しているが、仮にDeleteNoteメンバ関数が呼び出された直後にRegisterNameメンバ関数が呼び出されると、解放したm_noteの指すメモリ領域にアクセスできてしまう。これがbという脆弱性だ。例示プログラムでは、悪意をもつ利用者（以下、攻撃者という）の操作によって、任意の攻撃コードを実行され、サーバを乗っ取られてしまうおそれがある。

　Uさん：解放したメモリ領域にアクセスされると、どのように攻撃コードが実行されるのですか。 　T主任：例示プログラムにおいて、図3に示す(1)～(3)の順でメンバ関数の呼出しが行われたとしよう。その場合、図3の(1)で確保されていたNote構造体用のメモリ領域と、図3の(3)で確保されたchar[8]用のメモリ領域が同じアドレスに割り当てられる可能性がある。その場合、①RegisterNameメンバ関数内で読み込まれる攻撃者からの入力値によって、元々Note構造体用であったメモリ領域が上書きされる。このときの攻撃者からの入力値がうまく細工されていると、②次にRegisterNameメンバ関数が呼ばれた際、その際に読み込まれる攻撃者からの入力値が、攻撃者の指定したアドレスに書き込まれることになる。このように、攻撃者からの入力値が攻撃者の指定したアドレスに書き込まれる場合には攻撃コードが実行され得る。

　Uさん：もう少し具体的に説明してください。 　T主任：関数テーブルの例で説明しよう。ここでいう関数テーブルとは、プログラム中で呼び出している共有ライブラリに含まれる関数（以下、ライブラリ関数という）の実行コードの先頭アドレスが記録されたテーブルだ。ライブラリ関数の呼出し時には、図4に示すように関数テーブルに記録された実行コードの先頭アドレスの値を参照してライブラリ関数の実行コードに処理が遷移する。

　T主任：攻撃者が既に、攻撃コードをメモリ上に書き込んでいるとしよう。この状態で、例えば、攻撃コードが存在するアドレスを関数テーブルに書き込まれた場合、関数の呼出し時に関数テーブルが参照されると、攻撃コードに処理が遷移してしまう。 　Uさん：例示プログラムを攻撃する場合だと、関数テーブルに書き込むアドレスは具体的にどのような値になりますか。 　T主任：例えば、RegisterMsgメンバ関数の呼出しによってm_note->msgが指し示すメモリ領域に攻撃コードが書き込まれていて、その先頭アドレスが0x0b123400と分かっていたとする。その場合、関数テーブルが表1に示すようになっていたとすると、アドレスc番地に値dを書き込むことによって、次にCreateNoteメンバ関数が呼び出された際、攻撃コードに処理が遷移することになる。

　Uさん：RegisterMsgメンバ関数の呼出しによって入力された攻撃コードはe領域に書き込まれるので、データ実行防止と呼ばれる機能が有効化されていた場合、実行されませんよね。 　T主任：確かにそのとおりだ。ただし、③関数テーブルに書き込むアドレスとして、例えば、共有ライブラリ内のメモリアドレスを選べば、データ実行防止が有効化されていた場合でも、攻撃者が任意の処理を実行できる可能性がある。例示プログラムにおいて、共有ライブラリ内のメモリアドレスが表2のようになっていたとすると、関数テーブルに書き込むアドレスをf番地にすることによって、データ実行防止が有効化されていた場合でも、/bin/shを起動して任意のシェルコマンドを実行できる可能性がある。 　 ↩設問7

　Uさん：共有ライブラリ内のメモリアドレスは、表2のように前もって知ることができるものなのですか。 　T主任：共有ライブラリをメモリに読み込む際、それを配置するアドレスを毎回ランダムに選ぶASLR（Address Space Layout Randomization）と呼ばれるセキュリティ機能がある。この機能が有効な場合、共有ライブラリ内のメモリアドレスを前もって知ることは難しい。しかし、例示プログラムにおいて、図3の(3)の状態をつくり出せれば、RegisterNameメンバ関数とgメンバ関数を利用することによって、ASLRが有効化されていた場合でも、共有ライブラリ内のメモリアドレスを特定できる可能性がある。データ実行防止やASLRなどは効果的な機能ではあるが、根本的な対策にはならない。やはり脆弱性そのものを修正することが重要だ。 　Uさん：では、bの脆弱性を修正するには、例示プログラムではどうすればよいのでしょうか。 　T主任：図1の39行目の直後にhという1文を加えればよいだろう。 　 　Uさんは、今回学んだことをコードレビューの観点として生かしていくことにした。