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

解答の論理構成

1. 【問題文】には「脆弱性が報告されると、a識別子が付番され、日本国内ではJPCERT/CCなどが公表し注意喚起している。」とあります。世界共通で脆弱性を一意に識別する仕組みは “CVE（Common Vulnerabilities and Exposures）” であり、識別子は “CVE-2023-xxxx” のように付番されます。したがって a＝「ア：CVE」となります。
2. 次に「ただし、公表前に悪用されるものもあり、b脆弱性と呼ばれる。」とあります。公表（パッチ公開）前に攻撃に利用される脆弱性は “ゼロデイ脆弱性” です。よって b＝「イ：ゼロデイ」です。
3. 続けて「b脆弱性は、特定の組織を狙う攻撃、つまりc型攻撃でしばしば悪用される。」とあるため、特定組織を狙う攻撃＝“標的型攻撃” と分かります。ゆえに c＝「ウ：標的」です。
4. 「…静的解析ツールを利用したり、通常の利用では想定しないデータを入力し、その応答から脆弱性を探すd検査を行うツール…」とあり、想定外データを大量に与えてバグを探す手法は “ファジング（fuzzing）” です。従って d＝「エ：ファジング」となります。

誤りやすいポイント

• “CVE” を “CWE” と取り違えるケースが頻出します。CWE は脆弱性の種類分類、CVE は個別脆弱性の識別子です。
• “ゼロデイ” と “公開前” に関する記述を読み落とし、“深刻度が高い脆弱性” と誤解する受験生がいます。高リスク＝ゼロデイとは限りません。
• “標的型攻撃” を「APT」と英語表記で思い出し、選択肢にないため混乱するパターンがあります。日本語の「標的」が正解。
• “ファジング” 検査を「動的解析」とだけ覚え、選択肢に同義語がないため迷うことがあります。ファジングは動的解析の一種ですが、キーワードは“ファジング”です。

FAQ

解答の論理構成

1. 【問題文】では、スタックベース BOF 脆弱性について「①開発者が想定しないメモリ領域に書き込まれ、開発者の意図しない命令が実行される」と説明されています。
2. スタック領域には、関数呼出し時に「戻り先」を示す値が必ず積まれます。
3. 攻撃者は入力データでバッファをあふれさせ、この「戻り先」を自分の用意したアドレスに書き換えます。
4. 関数が ret 命令を実行すると、改ざんされた値を取り出してジャンプし、意図しない命令が実行される――すなわち攻撃が開始されます。
5. 以上より、書き換えられる値は「呼出し元関数への戻りアドレス」です。

誤りやすいポイント

• 「ローカル変数」や「スタックポインタ」を答えてしまう。実際に制御を奪う鍵は戻りアドレスです。
• ヒープベース BOF と混同し、malloc で確保した領域のメタデータを書き換えると誤解する。設問はスタックベース BOF について問われています。
• 「関数ポインタ」「システムコール番号」など、スタックに常に置かれるとは限らない情報を連想してしまう。

FAQ

解答の論理構成

1. 前提確認
   • 問題文には「実行権限の属性に“s”が表示されているファイルは、ファイルの所有者権限で実行されることを示している。」とあります。これは Unix 系 OS における set-user-ID (setuid) の説明です。
2. 判定条件
   • さらに「四つのファイルのうちアは、一般利用者suzukiによって起動された場合でもroot権限で動作する。」という記載から、アに入るのは
     (a) パーミッション欄に “s” がある
     (b) 所有者が root
     を同時に満たすファイルであると分かります。
3. 図1の読み取り
   • 図1（ls コマンド結果）を確認すると、“s” を含むファイルは 2 つありますが、所有者が root なのは sample2 だけです。
4. 結論
   • 以上より、ア に入るファイル名は「sample2」となります。

誤りやすいポイント

• “s” が付いていれば無条件に root で動作すると早合点し、所有者欄を見落とす。所有者が root でなければ setuid で実行しても root 権限にはなりません。
• “s” が group 権限位置に付いている setgid と混同する。設問は「root 権限で動作する」ため setuid（ユーザ側）の有無が鍵です。
• 図1の行を数えて上から順に選ぶなど、視覚的な並び順で判断してしまう。必ず属性と所有者を両方確認する必要があります。

FAQ

解答の論理構成

1. バッファの上限
   【問題文 図2 line 4】には #define UID_SIZE 8、【同 line 5】には #define PASS_SIZE 8 とあります。
   さらに【同 line 20】uid = new char[UID_SIZE+1];、【同 line 21】pass = new char[PASS_SIZE+1]; とあり、uid と pass はそれぞれ9 byte（8文字＋終端 \0）ずつヒープに確保されます。
2. ヒープ上の配置とコピー処理
   通常の環境では new の呼出順にメモリが確保されるため、uid が先頭、直後に pass が並ぶ形になります。
   【同 line 23】では strcpy(uid, argv[1]); が実行されますが、strcpy には長さチェックがありません。
   ① argv[1] が9文字を超えると uid の境界を越えて書込みが続き、先頭から9 byte目以降が pass の領域を上書きします（ヒープベース BOF）。
3. 認証処理に与える影響
   認証判定は【同 line 25】
   c if (strlen(pass) == 0 || strcmp(argv[2]、pass) != 0)
   で行われます。攻撃者が
   ・argv[1] の9～16文字目に好きな8文字を配置して pass を改ざん
   ・argv[2] に同じ8文字を与える
   ことで strlen(pass) != 0 かつ strcmp(argv[2]、pass) == 0 となり、認証を回避できます。
4. 解答群の照合
   ・記号「ウ」の第1引数は「011（繰返し）1111111101」と示され、前半8文字を超えた位置に「11111101」が出現します。
   ・同じ「11111101」が第2引数に指定されています。
   よって「ウ」は上記②③を同時に満たし、②引数によっては、利用者認証を回避できる唯一の組合せです。

誤りやすいポイント

• 「UID_SIZE 8」なので“8文字以内なら安全”と短絡し、\0 を含めた9 byte上限を見落とす。
• new によるヒープ配置は実装依存とされる点（本文下線③）を忘れ、「常に pass が uid の直後」と決めつける。
• strlen(pass)==0 だけを回避すれば良いと考え、strcmp の一致条件を意識せずに文字列長０の上書きだけを狙う。

FAQ

解答の論理構成

1. 図2のプログラムＹでは、利用者ＩＤ用にnew char[UID_SIZE+1]で確保した領域に対し、 制限なくコピーを行うコードが存在します。
2. そのコピーは 行番号「23」 のstrcpyで実施されます。strcpyは終端の '\0' までを無条件で転送する関数であり、長さチェックを行いません。
3. 仕様上、ＩＤは「最小 6 文字最大 8 文字」と定められていますが、攻撃者が 9 文字以上の値を 第1引数に渡せば、uid バッファが確保した 「UID_SIZE+1」(＝9) 以上の長さとなりヒープ領域を越えて隣接メモリを書き潰します。
4. この隣接メモリには、次行で参照されるpassポインタやメタデータが配置される可能性があり、 「②引数によっては、利用者認証を回避される可能性がある」状況が発生します。
5. そのため、実際にバッファがオーバフローする箇所は 行番号「23」 であり、模範解答「23」と一致します。

誤りやすいポイント

• getPass関数を疑い、行22を選んでしまう
  → あくまでコピーは行23で実施されるため、不正解になります。
• 「最大 8 文字なので問題ない」と思い込む
  → 入力値検証は呼び出し側で一切行われておらず、仕様違反の長さでもそのままコピーされます。
• スタックベースＢＯＦと混同し、ヒープ領域であることを見落とす
  → newで確保しているためヒープベースＢＯＦです。

FAQ

解答の論理構成

• 【問題文】では、利用者 ID の仕様を「“利用者 ID とパスワード”は、いずれも半角英数字、最小 6 文字最大 8 文字の文字列」と定め、ソースコード中で「#define UID_SIZE 8」と宣言しています。
• ところが行 23 で「strcpy(uid, argv[1]);」を実行しており、argv[1] が 9 文字以上のとき「uid = new char[UID_SIZE+1];」で確保した 9 バイトを超えて書き込み、【問題文】にある②引数によっては、利用者認証を回避される可能性を生むヒープベース BOF が発生します。
• 改修方針は「UID_SIZE+1 バイトを上限としてコピーを打ち切る」ことです。
  1. イ「memcpy(uid、argv[1]、UID_SIZE+1);」
     • コピー長を「UID_SIZE+1」で固定しているため確保領域を超えません。
  2. オ「strncpy(uid、argv[1]、UID_SIZE+1);」
     • strncpy も第 3 引数で上限を指定でき、ヒープ領域を超えない点で適切です。
• 他の選択肢を確認します。
  ・ア、エは「strlen(argv[1])+1」で計算した長さをそのままコピーするため、9 文字以上入力すると再び BOF が起きます。
  ・ウは確保領域を「PASS_SIZE+8」に変えても uid とは無関係で、根本的な対策になりません。
• 以上より、適切なのは「イ、オ」です。

誤りやすいポイント

• 「memcpy にすれば安全」という思い込み。コピー長に入力文字列長を使えば strcpy と同じ危険性があります。
• 「バッファを少し大きく取れば十分」と考え、データ仕様（最大 8 文字）を無視してしまう。
• strncpy を使えば必ずヌル終端されると誤解し、コピー後の終端確認を怠る。

FAQ

解答の論理構成

• 【問題文】では、下線部③として「このプログラムYは引数が同じでも、実行環境によっては利用者認証を回避されない」と述べています。
• ヒープベース BOF では、攻撃者は「先に確保したバッファをあふれさせて、後から確保した重要変数を書き換える」ことを狙います。
• ところがヒープ領域は、動的メモリ確保ライブラリ（malloc／new など）の実装や OS のバージョンによって「確保単位」「チャンクの並び順」「番兵領域の有無」が変わります。
• そのため、同じ順序で new を呼び出しても
  ・ある環境では「uid バッファ」の直後に「pass バッファ」が並び、あふれた文字列が pass を上書きし認証回避が成立
  ・別の環境では2つのバッファの間に隙間やガード領域が入り、上書きが届かず回避が失敗
  という差が生じます。
• よって、下線③の理由は「ヒープメモリの確保方法が、メモリ確保のライブラリによって違うから」となります。

誤りやすいポイント

• 「攻撃タイミングの違い」と誤解し、ヒープ配置の非決定性を見落とす。
• DEP や ASLR と混同し、「OS 保護機構が有効だから回避できない」と答えてしまう。
• スタック BOF と同じ感覚で「関数の戻り番地が書き換えられるか否か」が決め手だと勘違いする。
• 文字列長チェック不足ばかりに注目し、ヒープ上の物理的な配置が環境依存である事実をスルーする。

FAQ

解答の論理構成

1. 本文には「WindowsではハードウェアDEP（Data Execution Prevention）のようなデータ実行防止機能を適用することで、一部のBOF脆弱性を悪用する攻撃を抑制できる。しかし、④プログラムYでの利用者認証を回避する攻撃に対しては有効に機能しない」と明記されています。
2. DEPが防げるのは「メモリ上のデータ領域を実行不可にする」タイプの攻撃、すなわち“注入したシェルコードを実行させる”ケースです。
3. ところがプログラムYの攻撃は、図2のuid = new char[UID_SIZE+1];で確保したヒープ領域にstrcpy(uid, argv[1]);で境界を超えて書き込み、uidやpassなどの変数内容を改変しstrcmpの結果を偽装する“認証バイパス”であり、悪用の核心は「ヒープ領域の書き換え」です。
4. DEPは「実行」を防ぎますが「書き換え」そのものは防げません。従って本文④が示す通り、利用者認証を回避するヒープベースBOF攻撃には効果がありません。
5. 以上より、「ヒープ領域を書き換える行為を防止できないから」という解答が導かれます。

誤りやすいポイント

• 「DEP＝BOF全般に有効」と思い込み、データ改ざん型の攻撃にも効くと勘違いする。
• ヒープとスタックを混同し、スタック上でのコード実行阻止を理由にしてしまう。
• ④の文脈を読まず、「OS設定が無効」など方向違いの説明を書く。

FAQ