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

解答の論理構成

1. a の文脈
   • 原文引用：
     「開発元から提供されるaの適用やソフトウェアの更新によって、セキュリティホールに対処する。」
   • “開発元から提供される”かつ“セキュリティホールに対処”という説明は、一般に「セキュリティパッチ」を指します。
   • さらに「Webサーバにおいては、aの適用やソフトウェアの更新をしなくても」と続くため、対策手段としてのパッチが念頭に置かれていると判断できます。
     ⇒ a ＝ 「セキュリティパッチ」
2. b の文脈
   • 原文引用：
     「スタックバッファオーバフロー攻撃、bバッファオーバフロー攻撃や、静的メモリ領域を対象としたバッファオーバフロー攻撃が知られている。」
   • スタックに対比される動的メモリ領域は “ヒープ” であり、「ヒープバッファオーバフロー攻撃」は定番の分類です。
     ⇒ b ＝ 「ヒープ」
3. d の文脈
   • 原文引用：
     「libc共有ライブラリを利用する場合、この攻撃はd攻撃と呼ばれる。」
   • libcの既存関数へ制御を飛ばす古典的手法は「return-to-libc攻撃」です。
   • “任意のプログラムを実行できる関数を、スタックバッファオーバフロー攻撃時に利用”という説明もreturn-to-libcの特徴と一致します。
     ⇒ d ＝ 「return-to-libc」

誤りやすいポイント

• 「セキュリティパッチ」を「アップデートファイル」「修正プログラム」などと曖昧に書くと減点対象になりやすいです。
• ヒープとグローバル領域（BSS／データ領域）を混同し、「静的メモリ領域=ヒープ」と誤読してしまうケースがあります。
• return-to-libcをROP（Return Oriented Programming）と書く誤答が散見されます。ROPはより包括的な概念で、本問はlibcを明記している点が決め手です。

FAQ

解答の論理構成

1. 攻撃の成立条件を確認
   • 【問題文】には「図2中のshellコードは、攻撃者がスタックバッファオーバフロー攻撃によってメモリ上に配置するものである。」とあり、悪意のコードは「スタック領域」に置かれると明示されています。
2. シェルコード実行を阻止する仕組み
   • 同じく【問題文】で「指定されたメモリ領域でのコードの実行を禁止する機能（以下、データ実行防止機能という）」と紹介されており、これは“その領域を実行不可にする”ことで攻撃を防ぐ機能です。
3. どの領域を実行不可にすべきか
   • 攻撃者が配置するのは「スタック領域」にあるシェルコードなので、ここを実行不可に設定すればプログラムカウンタがスタックに移っても命令として解釈されません。
4. 結論
   • したがって、データ実行防止機能を適用すべきメモリ領域は「スタック領域」となります。

誤りやすいポイント

• 「ヒープ領域」や「BSS領域」もデータ領域なので誤答しやすいが、本問でシェルコードが載るのはスタックであり、他領域に配置されるケースは示されていない。
• 「共有ライブラリ」を実行不可にするという考え違い。共有ライブラリは正規の実行コードであり、実行不可にすると通常動作まで阻害される。
• データ実行防止機能は“全メモリを対象にする”と早合点してしまう。実際にはセグメント単位で細かく制御でき、必要最小限の領域だけを実行不可にするのが基本。

FAQ

解答の導き方

• "char c[24]" のアドレスは "c8047fe6"
• "リターンアドレスX" のアドレスは "c8048026"
• "（ここにshellコードが入る）" の領域は、図の描き方からその下端（低いアドレス側）が "c8048026" で、上端（高いアドレス側）が "c804805e" になっていることが読み取れます。したがってシェルコードの先頭（実行開始すべき最初のバイト）はアドレス "c8048026" に位置します。

• インジェクションベクタの先頭バイト → アドレスc8047fe6
• …
• インジェクションベクタの64バイト目（オフセット0x40）まででアドレスはc8048025まで埋まるため、インジェクションベクタの次の4バイト（図3の c）がメモリ上でアドレスc8048026 ～ c8048029の領域に書かれ、これが「リターンアドレス」を上書きします（差分計算：c8048026 - c8047fe6 = 0x40 = 64）。
• その後に続くバイト群が更に上のアドレスへ入り、図2に描かれた "shellコード" の領域を形成します。

誤りやすいポイント

• 図2のアドレス表示の上下（図の上側＝大きいアドレス／下側＝小さいアドレス）を取り違えると、シェルコードの「先頭」アドレスを逆に解釈してしまいます。図中の矩形の「下端（低いアドレス側）」が実行開始点である点を必ず確認してください。
• インジェクションベクタの左端がメモリの低いアドレスに対応すること（strcpyの書き込み方向）を誤解すると、オフセットの向きが逆になってしまいます。
• オフバイワン（何バイト目がリターンアドレスに対応するか）の計算ミス。今回はc8048026 - c8047fe6 = 0x40（64）であることを正確に求める必要があります。
• リトルエンディアンを忘れて、アドレスをそのまま "c8048026" と4バイト列にしてしまうミス。メモリには下位バイトが先に置かれます。

FAQ

解答の論理構成

1. 攻撃者は図3のインジェクションベクタで「リターンアドレス」を上書きし、プログラムの制御をshellコードや共有ライブラリ内部に飛ばすことで任意コード実行を狙います。
2. その際に不可欠なのが「飛び先の実メモリアドレスを正確に書き込む」行為です。
3. 【問題文】には、アドレス空間配置ランダム化技術について
   　“最近のOSでは、こういった攻撃が成功することを抑制するため、アドレス空間配置ランダム化技術が実装されている”
   　とあり、OS起動やプロセス実行のたびにスタック・ヒープ・共有ライブラリ・実行ファイル等の配置アドレスをランダム化することが示唆されています。
4. アドレスが毎回変われば、攻撃者は「ジャンプ先アドレス」を事前に決め打ちできず、図3のベクタに正しい値を埋め込めません。
5. したがって、「攻撃を成功させるためのジャンプ先アドレスの特定」を不能にすることが、成功率を大きく下げる直接要因となります。

誤りやすいポイント

• 「ASLRはコード実行そのものを禁止する」と誤解し、制御移譲の鍵となるアドレス特定阻止という本質を外す。
• スタック破壊検知機能やデータ実行防止機能と混同し、「実行可能／非実行可能の切替」と答えてしまう。
• “ランダム化でシェルコードを置けなくなる”と表現し、シェルコードの配置自体は可能である点を見落とす。

FAQ

解答の論理構成

1. 問題文は「①通信路上にIPSやWAFを設置することによって、インターネットからWebサーバへのバッファオーバフロー攻撃を防止することもできる」と述べています。
2. IPS／WAFはネットワーク上の通信内容を解析し、攻撃パターンに合致するデータを遮断する製品です。バッファオーバフロー攻撃では、攻撃用のデータ列（本文では「インジェクションベクタ」）がリクエスト中に含まれます。
3. したがって、IPS／WAFが行う具体的処理は「インジェクションベクタを識別して通信を止める」ことになります。
4. 以上から模範解答「インジェクションベクタを検知・破棄する。」となります。

誤りやすいポイント

• IPS／WAFの役割を「暗号化」「アクセス制御」と誤解しやすい。ここではペイロード解析による攻撃データの遮断が本質です。
• 「バッファオーバフロー全体を防ぐ」とだけ書くと、具体的処理を問う設問意図から外れて減点対象になります。
• 「パケットを破棄」とだけ書くと、何を根拠に破棄するのかが不明確で説明不足になります。

FAQ

解答の論理構成

1. 問題文は、スタックバッファオーバフロー攻撃によって「shellコードにプログラムの制御が移ってしまう」ことを説明したうえで、 「Vulnが実行時に②一定の条件を満たせば、あらゆる命令の実行がshellコードで可能となる」
   と述べています。
2. ここで「あらゆる命令」とは、OS全体を支配するようなシステムコールの実行を含みます。OSが備える保護機構を回避して完全掌握するためには、プロセスが最上位権限（スーパーユーザ権限）で動いている必要があります。
3. 同じ本文中には、スマホに関する説明として
   「スマホのルート特権を利用者が利用できる状態にする行為（以下、ルート特権化という）」
   という定義が登場しており、ルート特権化された端末では「データを盗み出すタイプのマルウェア」が「ルート特権を取得」して多大な影響を及ぼすリスクが強調されています。
4. 以上より、スタックバッファオーバフローでshellコードが“何でもできる”状態になる条件は、対象プロセス（今回のVulnプログラム）が「ルート特権」で実行されていることです。
5. 従って、下線②の条件は「ルート特権があること」となります。

誤りやすいポイント

• DEP（データ実行防止機能）やASLRが無効であることを条件と誤解しやすい。本文は「一定の条件」を“権限”の話としており、メモリ保護機構の有無とは別問題です。
• 「スタック破壊検知機能を含めずにコンパイルしていること」が条件だと考えてしまう。これは攻撃成功率を高める要因であって、“あらゆる命令”を実行できるかどうかを決める条件ではありません。
• インジェクションベクタの長さやshellコードの配置アドレスを条件と勘違いするケース。これらは攻撃のテクニカルな要件であり、問題文の「一定の条件」の主眼ではありません。

FAQ

解答の論理構成

1. 【問題文】では「ルート特権化されたスマホでは、“データを盗み出すタイプのマルウェア”が侵入してしまうと、それがルート特権を取得して、③スマホ内に保存されているアプリのデータを不正に読み出してしまうリスクが高まる」と述べています。
2. 逆に言えば、ルート特権化されていないスマホでは、この“不正な読出し”がOSの仕様で制限されていることになります。
3. 多くのスマホOS（AndroidやiOS）は、アプリごとに専用のユーザIDを割り当て、アプリのデータ領域をそのユーザIDだけが読み書きできるようにファイルシステム上で分離しています。この仕組みは一般に「サンドボックス」と呼ばれます。
4. したがって、通常権限のアプリは「ほかのアプリのデータ」を参照できません。ルート特権を得たときのみ、このUIDベースのアクセス制御を迂回できるため、上記のリスクが顕在化します。
5. 以上より、解答は「あるアプリから、ほかのアプリのデータへのアクセスを禁止するという仕様」となります。

誤りやすいポイント

• 「暗号化しているから読めない」と考える誤解
  → 問題が訊いているのはファイルシステムのアクセス制御であり、暗号化の有無は問われていません。
• 「Mシステムでリモートワイプできるから安全」と答えてしまう
  → リモートワイプは紛失対策であり、アプリ間アクセス制御とは別の話題です。
• サンドボックス＝ウイルス対策ソフトと混同する
  → サンドボックスはOSレベルの権限分離、ウイルス対策ソフトはアプリケーション層の防御で目的が異なります。

FAQ

解答の導き方

1. 本文はまず、K社の調査で「ルート特権化は、主に、バッファオーバフロー攻撃を用いて実現されることが分かった」と記しています。これは攻撃者が脆弱なプログラムに対してデータを注入し、図3のようなインジェクションベクタで図2のshellコードを配置して任意命令を実行することで権限を奪うことを意味します。
2. 次に本文は、ルート化された端末について「“データを盗み出すタイプのマルウェア”が侵入してしまうと、それがルート特権を取得して、スマホ内に保存されているアプリのデータを不正に読み出してしまうリスクが高まる」と述べています。ここから、マルウェアが侵入して端末内で権限昇格（ルート取得）を行うことが問題であると読み取れます。
3. 以上を合わせると、利用者が規程を守って意図的にルート化していなくても、マルウェアや脆弱性を突く攻撃によって端末が勝手にルート化される状況が想定されます。したがって設問にふさわしい表現は「ルート特権化するマルウェアに感染したとき」です。

誤りやすいポイント

• 利用者が自らルート化しない限り意図しないルート化は起こらないと考える誤り。本文はマルウェアや脆弱性攻撃を原因として明示しています。
• 「古いOSだからだけが原因」と単純化する誤り。確かに脆弱性は関係しますが、攻撃手法（マルウェアやバッファオーバフロー）が直接の誘因です。
• 図の細部（図2／図3）を見落とし「root化＝ユーザ操作のみ」と誤解すること。図は攻撃により任意コードが実行され得ることを示しています。
• 設問の下線番号や該当箇所を間違えて参照することで、根拠のずれた説明をする誤り。

FAQ

解答の論理構成

1. 【問題文】には、スマートフォン管理用として「スマホを遠隔で管理するシステム（以下、Mシステムという）」を導入し、 “スマホのOSやアプリのバージョンなどの構成情報の管理” まで実施できると明記されています。
2. さらに〔K社での対策〕で、“スマホのOSのバージョンをK社が確認する運用策を実施することにした” とあります。
3. すでに “構成情報の管理” 機能を備えた「Mシステム」が稼働しているため、追加の仕組みを用意せずとも同システムでバージョン確認が完結します。
4. よって、下線⑤の具体的な確認方法は「Mシステムを使って確認する。」となります。

誤りやすいポイント

• “Bシステム用のアプリ” と混同し、メールやグループウェアの画面から手動確認と答えてしまう。
• 既存の資産管理台帳や申請書を想起し、紙ベースの確認策を挙げてしまう。
• 「Mシステム」の役割が“遠隔ワイプ”と“紛失時対策”だけだと思い込み、バージョン情報収集機能を見落とす。

FAQ