情報処理安全確保支援士 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では、ユーザID用バッファを
   uid = new char[UID_SIZE+1];
   (ここで "UID_SIZE 8")
   により9 byte、続いてパスワード用バッファを
   pass = new char[PASS_SIZE+1];
   (ここで "PASS_SIZE 8")
   により9 byte確保しています。ヒープでは通常、先に確保した領域（uid）の直後に後の領域（pass）が並びます。
2. 取得した正規パスワードをいったん
   getPass(pass, argv[1]);
   で pass に格納した後、次の一文が問題です。
   strcpy(uid, argv[1]);
   strcpyは長さチェックを行わず、第1引数（argv[1]）を NUL終端まで uidに書き込みます。
   • 8文字を超える入力 → uidを越えて pass 領域へ上書き → “ヒープベースBOF” 発生
3. 認証判定は
   strlen(pass) == 0 || strcmp(argv[2]、 pass) != 0
   です。攻撃者が
   ① argv[1] を17 byte（uid9 byte＋pass8 byte）以上にし、後半8 byteを任意値で上書き
   ② argv[2] にその8 byteと同じ値を入れる
   と、strcmpが一致して 「認証成功」 となります。
   表の候補中、この条件を満たすのは以下の組です。
   • 第１引数「011（繰返し）1111111101」は17文字で、先頭9文字 (uidと終端のNUL文字) を超えた後半8文字「11111101」を pass に上書き
   • 第２引数「11111101」はpassが書き換えられた値と完全一致
   他の候補は
   – 上書き文字数が8 byteに足りない
   – 第２引数と後半8 byteが一致しない
   などで条件を満たしません。したがって解答は 「ウ」 になります。
   これが本文の下線②「引数によっては、利用者認証を回避される可能性」の具体例です。

誤りやすいポイント

• 「UID_SIZE+1」で9 byte確保しているため、NUL文字も領域に含まれる点を忘れると必要なオーバフロー長を誤算します。
• ヒープの配置は処理系依存であるため、下線③「実行環境によっては利用者認証を回避されない」を見落として「必ず成功する」と断定しがちです。
• getPassが先にpassを設定する流れを追わず、「認証時に再取得するはず」と思い込むと、上書きのタイミングを誤解します。
• DEPやASLRなどの実行制御系の防御は「コード実行阻止」には効いても、「データ改竄だけで成立する認証回避」には無力な点を混同しやすいです。

FAQ

解答の導き方

1. バッファサイズと確保箇所を確認する。図2に "#define UID_SIZE 8 // 利用者IDの文字列の上限値" とあり、
   "uid = new char[UID_SIZE+1];"（20行目）でuid用バッファをヒープに確保しています。passについても "pass = new char[PASS_SIZE+1];"（21行目）でヒープに確保しています。これにより該当バッファはヒープ上に存在することが分かります。
2. データの入出力の順序を見る。図2では先に "getPass(pass, argv[1]);"（22行目）が呼ばれ、ここでpassに登録済パスワードが格納されます（利用者IDが存在しない場合は長さ0の文字列を格納するという仕様も記載されています）。その直後に "strcpy(uid, argv[1]);"（23行目）が実行されます。つまり、passに値が入った後でuidへ無条件にコピーが行われます。
3. なぜ23行目でオーバーフローするかを数式で示す。argv[1] の文字数を $N$ とすると、strcpyは末尾のヌル文字を含めて $N+1$ バイトをコピーします。uid用に確保したバッファサイズは $UID\_SIZE+1=8+1=9$ バイトです。したがって コピー量がバッファを超える条件は $N+1>9$、すなわち $N\ge 9$ です。仕様上は利用者IDは最大8文字と定められていますが、プログラム側で長さチェックをしていないため、長い引数を与えればオーバーフローが発生します。
4. なぜ認証回避につながるか。オーバーフローはuidバッファの直後のヒープ領域を上書きします。図2の確保順（uidを先に確保し、その後passを確保）や一般的なヒープ配置のされ方から、オーバーフローによりpassに確保した領域の内容が書き換えられる可能性があります。getPassは先にpassに正しいパスワードを格納しているため、strcpyによる上書きでpassの内容が攻撃者の任意の値（例えばargv[2] と同じ値）に書き換わると、条件式 "if (strlen(pass) == 0 || strcmp(argv[2]、 pass) != 0) {" のstrcmpが0（等しい）を返し、認証判定をすり抜けて "認証成功"（28行目）の分岐に入ることがあり得ます。以上より、実際にバッファがオーバーフローするコードの行は23行目の "strcpy(uid, argv[1]);" です。

誤りやすいポイント

• passポインタ（変数本体）がオーバーフローで上書きされると考える誤り。passは "static char *pass;"（18行目）として宣言されており、ポインタ変数本体は静的領域（データ領域）に置かれます。オーバーフローで上書きされるのはヒープ上の領域（passが指すバッファの内容やヒープメタデータ）であり、ポインタ変数そのものとは限りません。
• スタックベースのBOFと同じ振る舞いを想定する誤り。ここではnewによるヒープ確保なのでヒープ上の隣接領域やメタデータが影響を受けます。
• UID_SIZE = 8だから「8文字でオーバーフローする」と誤って覚える。実際はヌル文字分を含めて $UID\_SIZE+1=9$ バイト確保なので、オーバーフローは $N\ge 9$（9文字以上）のときに発生します。
• DEP（NX）などのデータ実行防止機能でこの攻撃が防げると考える誤り。今回の攻撃はデータの改変（認証情報の上書き）を狙うもので、必ずしも実行可能領域へのコード注入／実行を伴わないため、DEPは有効とは限りません（問題文でも同様の指摘があります）。

FAQ

解答の導き方

1. なぜ脆弱性が起きるか
   • uidとpassをそれぞれヒープ上に確保しており、コードは先にuidをnewし、その後にpassをnewしています。つまりヒープ上でuidの領域が先に割り当てられ、その直後にpassが割り当てられる可能性が高く、長いargv[1] を「strcpy(uid, argv[1]);」で書き込むとuidの境界を越えて後続のヒープ領域（例えばpass）を上書きすることがあり得ます（ヒープベースBOF）。
   • getPass(pass, argv[1]) が先に呼ばれてpassに登録パスワードを格納しているため、strcpyによる上書きでpassの内容を攻撃者が書き換えれば、strcmpの比較を整合させて認証を通す（利用者認証の回避）ことが可能です。
2. 実行環境依存性の理由
   • 問題文にあるように「引数が同じでも、実行環境によっては利用者認証を回避されない」ことがあるのは、ヒープの割り当て順序やアロケータ、ASLR等によりuidとpassの物理的配置が変わり、オーバーフローがpassに到達するかどうかが変わるためです。
3. 選択肢の評価（各置換案を順に検討）
   • ア：memcpy(uid、argv[1]、strlen(argv[1])+1);
     • コピー長をstrlen(argv[1])+1にしているため、argv[1] の長さがUID_SIZEを超えるとuidの確保領域を越えて書き込む（書き込み側でオーバーフローする）。したがってオーバーフロー対策にならないため不適切です。
   • イ：memcpy(uid、argv[1]、UID_SIZE+1);
     • 書き込み長をUID_SIZE+1（uidの確保サイズ）に固定しているため、書き込みが確保領域を超えてpassを上書きすることは防げます。ただしmemcpyは指定したバイト数だけ「読み出す」ので、argv[1] が短い場合にソース側（argv[1]）のヌル終端を越えて読み出すことになり、未定義動作（読み出し側の越境）を招く点に注意が必要です。とはいえ与えられた選択肢の中では書き込み長を固定してオーバーフローを防ぐという観点で許容されます。
   • ウ：pass=new char[PASS_SIZE+8];
     • passの確保サイズを増やすだけではstrcpyがuidの境界を越える根本原因を解決しません。ヒープ上の配置や他のデータを破壊する可能性は残るため根本対策ではなく不適切です。
   • エ：strncpy(uid、argv[1]、strlen(argv[1])+1);
     • コピー長をstrlen(argv[1])+1にしており、argv[1] が長い場合は書き込み側がオーバーフローするため不適切です。
   • オ：strncpy(uid、argv[1]、UID_SIZE+1);
     • コピー長をUID_SIZE+1に制限するため、書き込みが確保領域を越えることは防げます。strncpyはソースが短ければ残りをヌルで埋めるのでargv[1] が短い場合は安全にヌル終端されます。ソースがUID_SIZE+1以上の長さの場合はヌル終端が保証されない点に注意が必要ですが、書き込み長の観点ではオーバーフローを防ぐため許容されます。

誤りやすいポイント

• memcpy(uid、argv[1]、UID_SIZE+1) を「完全に安全」と誤解する。memcpyは読み出し長を指定した通りに読むため、argv[1] が短いとソース側の越境（未定義動作）を招く可能性がある。
• strncpy(uid、argv[1]、UID_SIZE+1) が常にヌル終端を保証すると誤解する。ソース長が指定長以上ならヌル終端はされないので、必ず末尾を明示的に '\0' にする等の措置が必要。
• バッファを単に大きくする（ウ）ことで問題解決したと考える。根本的な境界チェックをしない限り他の領域破壊や未定義動作のリスクは残る。
• ヒープ領域の配置に依存して「ある環境では動かない＝脆弱性ではない」と誤認する。攻撃者は適切な環境や工夫で利用可能にすることがあるため、条件に依存する脆弱性でも修正が必要。

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