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

解答の論理構成

1. 【問題文】には「そのデータによって、aがあに書き換えられると、関数fooの終了時にshellコードへ処理が遷移する。」とあり、図2ではスタック上に「リターンアドレスX」が示されています。スタックバッファオーバフローで最終的に書き換えるターゲットはリターンアドレスであるため、a＝「リターンアドレスX」すなわち記号「キ」と判断します。
2. 次に「攻撃者が、DEPを回避するため…b中の実行可能なコードやc領域にマップされているVulnの断片コードを利用するケースがある。」との記述を参照します。
   • 図2にはスタックより下位に「ライブラリ」、さらに下位に「Vuln ⇒ テキスト領域」が描かれています。
   • 従って、b＝「ライブラリ」→記号「カ」、c＝「テキスト」→記号「ウ」と対応付けられます。
3. 「例えば、a攻撃の際、aをb関数の先頭アドレスで書き換えて、攻撃者の意図したb関数を呼び出すd攻撃もある」と続きます。ライブラリに存在する既存関数（典型的には“system”など）を呼び出す古典的手法は“Return-to-libc”攻撃です。したがって、d＝「Return-to-libc」→記号「ア」と決まります。
4. 以上を整理すると
   a＝キ、b＝カ、c＝ウ、d＝ア となり、模範解答と完全に一致します。

誤りやすいポイント

• aとオ「ベースポインタレジスタ保存値」を取り違える。スタック保護機構の説明にベースポインタが出てくるため混同しやすいですが、実際に乗っ取るターゲットはリターンアドレスです。
• bを「ヒープ」と誤答するケース。図2に「ヒープ」も描かれているものの、文中で“実行可能なコード”と書かれているため、通常 NX/DEP の下でも実行可能属性が付いている「ライブラリ」が正しいと気付きたいところです。
• dを「ROP」と選択するミス。ROP も DEP 回避技術ですが、文中の「b関数の先頭アドレスで書き換えて直接呼び出す」という説明は典型的 Return-to-libc の動作を指します。

FAQ

解答の論理構成

1. 問題文の前提
   • 「プログラム実行時に、変数bが指し示すデータが不正な場合、そのデータによって、aがあに書き換えられると、関数fooの終了時にshellコードへ処理が遷移する。」
   • ここで「a」はスタックに保存された「リターンアドレス」を指す。従って あ には「shellコードの先頭アドレス」を書き込む必要がある。
2. 図2の読み取り
   • 図2にはスタック領域の上部に「（ここにshellコードが入っている。）」と示され、その近くに ㋑ と ㋒ のアドレスが並ぶ。
   • スタック上のコードに制御を移したいので、スタック領域内を示すアドレスを選ぶ必要がある。
3. 各アドレスの意味
   • ㋐「ffffffff」：カーネル空間の終了番地でありユーザープロセスからは実行できない。
   • ㋔「08048350」：テキスト領域（実行ファイル本体）。DEP 回避を目的とする今回の攻撃では使わない。
   • ㋓「bfffdf000」：問題文において「char d[100]」が割り当てられている地点。ここに書き込むとシェルコードではなくバッファ領域に飛んでしまう。
   • ㋑「bfffff2bc」および ㋒「bfffff29d」：どちらもスタック上端付近だが、図2では ㋒ が「shellコード」が配置された行と一致している。
4. 結論
   • 「shellコードへ処理が遷移する」条件を満たすアドレスは「bfffff29d」。
   • よって、選択肢は「㋒」。

誤りやすいポイント

• ㋓「bfffdf000」を選んでしまう
  「char d[100]」の開始地点なので、飛んでもシェルコードではなくデータ領域を実行することになりクラッシュする可能性が高いです。
• ㋔「08048350」を選んでしまう
  テキスト領域は DEP により実行可能ですが、問題文の設定は「スタックに置いた shell コード」に飛ばす攻撃なので前提が異なります。
• スタックのアドレス成長方向を誤解する
  x86/Linux ではスタックは高位アドレスから低位アドレスへ伸長します。図の上部ほど高位アドレスである点に注意が必要です。

FAQ

解答の論理構成

1. 【問題文】では、攻撃手順として「aがあに書き換えられると、関数fooの終了時にshellコードへ処理が遷移する。」と説明しています。つまり攻撃者はスタック上に置いた shell コードを実行させたい意図です。
2. ところが同じ段落の後半で「①このような遷移があっても、データ実行防止機能（以下、DEPという）が機能していると、攻撃は成功しない」と明記されています。
3. DEP は “実行不可属性” を利用し、スタックやヒープなどデータ領域を「実行できない領域」に設定します。そのためリターンアドレスを書き換えてスタック上の shell コードへ飛んだとしても CPU が命令として実行せず例外を発生させます。
4. よって結論は「スタック領域にある shell コードは DEP によって実行を拒否される」ことが攻撃失敗の理由となります。

誤りやすいポイント

• DEP を「アドレスをランダムにする機能」と誤解し、ASLR の説明を書いてしまう。
• 「スタックが書き換えられないから失敗する」と書いてしまい、DEP の“実行禁止”という本質を外す。
• shell コードがヒープやライブラリにあれば成功すると混同し、スタックに限定した説明を落とす。

FAQ

解答の論理構成

1. 【問題文】では
   “関数fooを呼び出す際、図2のベースポインタレジスタ保存値より下位にeが挿入される。もしも、eが上書きされた場合は、攻撃と判断し、Vulnの実行を停止する。”
   とあり、これはスタックバッファオーバフロー検知の典型手順です。
   表1の「SSP (Stack Smashing Protection)」の概要には
   “スタック領域で canary と呼ばれる値を利用してスタックバッファオーバフローの有無を確認する技術”
   と明記されています。したがって e には “canary” が入ります。
2. 続いて
   “その対策としては、ライブラリ関数のアドレス推定を困難にさせるfが有効である。”
   と記述されています。攻撃者がコードリユース攻撃を行うためには関数やライブラリの絶対アドレスを知る必要があります。
   表1の「ASLR (Address Space Layout Randomization)」の概要は
   “プログラムの実行時に、データ領域、ヒープ領域、スタック領域及びライブラリを、ランダムにマップする OS の技術”
   であり、まさにアドレス推定を難しくします。したがって f には “ASLR” が入ります。
3. よって解答は
   e：canary
   f：ASLR
   となります。

誤りやすいポイント

• SSP と DEP を混同する
  DEP は「実行不可ページ」を設定して 実行 を防ぎますが、スタック領域に特別な値を置いて改ざん検知を行うのは SSP です。
• “アドレス推定を困難にさせる”というキーワードから PIE を選んでしまう
  PIE は実行ファイルのテキスト領域までランダム化しますが、根本原理は OS の ASLR に依存します。問題文で “ライブラリ関数のアドレス” と限定しているので ASLR が正解です。
• canary の位置を誤解する
  canary は「ベースポインタレジスタ保存値より下位」、つまりリターンアドレスよりも手前に配置されることを押さえましょう。

FAQ

解答の論理構成

1. 本文には「Automatic Fortificationによって、ライブラリ関数gを安全な関数に置き換えることで、バッファオーバフローの原因を排除することができる。」とあります。
2. Automatic Fortification が対象にするのは、境界チェックを行わずにバッファへ書き込むことで有名な C 標準ライブラリ関数です。
3. 中でもバッファサイズを確認せずにコピーを行う代表例が「strcpy」。この関数が原因でスタックバッファオーバフローが発生し得ることは、試験でも頻出の定番知識です。
4. よって、g に入るのは「strcpy」と判断できます。

誤りやすいポイント

• 「gets」「strcat」など他の危険関数と混同する。Automatic Fortification が最優先で置換する代表格は「strcpy」であることを押さえましょう。
• 「memcpy」はコピー長を明示的に渡すため、境界未チェックという点では「strcpy」ほど危険度が高くありません。
• ASLR や SSP など他の対策技術と役割を混同し、Automatic Fortification の着目点（コンパイル時に脆弱な関数を差し替える）を見落とす。

FAQ

解答の論理構成

• 【問題文】には “②Automatic Fortificationではバッファオーバフローの原因を排除できないケース” とあります。
• 表1で “Automatic Fortification” は「バッファオーバーフロー脆弱性の原因となりうる脆弱なライブラリ関数を、コンパイル時に境界チェックを行う安全な関数に置換する技術」と説明されています。
  → 置換対象はあくまで “ライブラリ関数” です。
• 図1のプログラムでは
  “16: while ((s1[i++] = *errmsg++) != '\0');”
  と、自前の while ループで *errmsg の内容を s1 に 1 文字ずつ代入しています。
  → strcpy、strncpy などのライブラリ関数を使っておらず、ポインタ演算で直接メモリを書き換えています。
• したがって Automatic Fortification が介入できず、バッファ境界チェックは行われません。
  → 排除できないケースに該当する行は “16行目” となり、理由は「ポインタを使って直接メモリ操作しているから」です。

誤りやすいポイント

• strcpy(d, b)（7行目）もバッファオーバーフロー原因ですが、Automatic Fortification で置換可能なため “排除できないケース” には当たりません。
• fprintf などの I/O 関数はバッファコピーを伴わないため、対象外です。
• 「ポインタを使う＝必ず危険」ではなく、境界確認の有無が判断基準になります。問題では“ライブラリ関数を介さない”点に着目しましょう。

FAQ

解答の論理構成

1. 問題文は「ソースコードに脆弱性があっても、SSPを適用してコンパイルしていると、メモリ破壊攻撃が成立しないが、そのソースコードを③別の開発環境でコンパイルすると問題となる場合がある」と述べています。
2. ここでの“問題”とは、SSP が効かなくなることで「メモリ破壊攻撃が成立する」危険が再び顕在化する点です。
3. では「別の開発環境」とは何か。SSP は「スタック領域で canary と呼ばれる値を利用してスタックバッファオーバフローの有無を確認する技術」であり、
   • コンパイラが SSP 対応オプションを持っている
   • そのオプションを有効にしてビルドする
     という前提が必要です。
4. したがって「SSP を適用できないコンパイラ」や「SSP を無効にしてビルドする設定」の開発環境で再コンパイルすると canary が挿入されず、攻撃を抑止できません。
5. 以上より、 • 問題：メモリ破壊攻撃を防げないこと
   • 開発環境：SSP を適用できないコンパイラを利用する開発環境
   となります。

誤りやすいポイント

• 「別の開発環境」を OS の違いと誤読し、コンパイラ要件を見落とす。
• 「メモリ破壊攻撃が成立しない」を“脆弱性が消える”と誤解し、対策不要と判断してしまう。
• SSP を “実行時機能”と認識し、ビルド時に無効化されるリスクを考慮しない。

FAQ