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

解答の論理構成

1. 【問題文】図6では
   string::iterator readPoint = src.a();
   string::iterator atEOL = src.b();
   と記述されており、readPoint と atEOL の 2 つの反復子（イテレータ）で文字列 src 全体を走査しています。
2. ループ条件は
   while(readPoint != atEOL){ … }
   です。反復子が「先頭から末尾（終端位置）まで」を指し示すのが自然でなければ、この条件は成立しません。
3. 標準C++ライブラリ string クラスの代表的なメンバ関数は
   • begin() : 先頭要素を指すイテレータを返す
   • end() : 末尾の次（終端）を指すイテレータを返す
   です。その他の候補（clear、size など）はイテレータを返さない、あるいは意味が合致しません。
4. したがって
   ・readPoint は先頭を指す必要があるため a に入るのは “begin”
   ・atEOL は終端を指す必要があるため b に入るのは “end”
   となり、解答は
   a：ア
   b：ウ
   で確定します。

誤りやすいポイント

• size() と混同する
  size() は要素数を返す関数でありイテレータ型ではないため、代入自体がコンパイルエラーになります。
• 末尾位置のイメージ違い
  end() が「最後の文字」ではなく「最後の次」を指すイテレータである点を忘れると、ループ条件を誤って「<=」などに置き換えてしまい off-by-one エラーを招きます。
• clear() の機能誤認
  イテレータを返しそうに見えても、clear() は内容を消去する副作用のみを持つため全く用途が異なります。

FAQ

解答の論理構成

1. 脆弱性の種類を確認
   問題文には「パーセントエンコード関数にバッファオーバーフロー脆弱性があり」と明示されており、対象は「図4」の関数です。
2. 書き込み先バッファの特定
   「図4」1 行目に
   void urlPercentEncode(char *dst, char *src, int n)
   とあり、dst が書き込み先バッファであることが分かります。
3. 上限チェックの不備
   ループ条件は 6 行目
   while(src[srcPos] != '\0' && dstPos < n){
   で行っていますが、エンコード対象文字の場合は 18〜22 行目で 最大３バイト を一度に dst に書き込みます。
   dst[dstPos++] = '%'; // 1 バイト ... dst[dstPos++] = x; // 2 バイト目 ... dst[dstPos++] = x; // 3 バイト目
   しかし dstPos < n の判定は １回のループ開始時点のみ なので、ループ途中で n を超過してもチェックされず、dst の後続領域に上書きが発生します。
4. 被害が出る領域
   問題文は「隣接したメモリ領域に置かれたフラグ変数が想定外の値に書き換えられる」と説明しており、これは dst の直後にあった変数への不正書き込みです。
   したがって、オーバフローが起きるメモリ領域は「dst が指し示す領域」と結論付けられます。

誤りやすいポイント

• src 側を疑ってしまう
  読み出しバッファである src はサイズを超えて読み込まれてもメモリアクセス違反になりにくく、今回の脆弱性の直接原因ではありません。
• n のチェックは十分と誤認
  １ループ３バイト書き込む場合があることに気付かないと、条件式 dstPos < n で十分と勘違いしやすいです。
• 「フラグ変数」そのものを回答に書く
  設問は「バッファオーバフローが発生するメモリ領域」を聞いており、書き換えられた側ではなく あふれ出した側 を答える必要があります。

FAQ

解答の論理構成

1. 【問題文】の「パーセントエンコード関数にバッファオーバーフロー脆弱性があり」とあるとおり、原因は urlPercentEncode() 内の領域管理にあります。
2. 図4‐6 行目の while 条件は
   while(src[srcPos] != '\0' && dstPos < n){
   で、dstPos < n という“1 バイト以上空いていれば継続”という判定しか行っていません。
3. しかし図4‐18～22 行目ではエンコード対象文字を見つけると
   dst[dstPos++] = '%'; // 1 バイト x = (src[srcPos] & 0x00f0) >> 4; dst[dstPos++] = …; // 2 バイト目 x = src[srcPos++] & 0x000f; dst[dstPos++] = …; // 3 バイト目
   の計 3 バイトを書き込みます。
4. したがって、ループ開始時点で n - dstPos が「1 バイトまたは 2 バイト」しか残っていない状態でエンコード対象文字が現れると、3 バイト目の書込みで dst の領域外に到達し、隣接メモリ（フラグ変数など）を上書きしてバッファオーバフローが発生します。
5. よって模範解答は「dst が指し示す領域の残りが 2 バイト以下となった時点で、src にエンコードすべき文字があった場合」となります。

誤りやすいポイント

• 「ナル終端を付与できないだけ」と思い込み、3 バイト連続書込みによる境界超過を見落とす。
• dstPos < n なので安全だと早合点し、必要バイト数（1 文字で最大 3 バイト）を考慮しない。
• 逆に「残り 1 バイトのときのみ危険」と狭く捉え、2 バイト残りの場合を失念する。
• src 側の読込位置（srcPos）ばかり注視し、dst 側の書込み量を軽視する。

FAQ

解答の論理構成

• 【問題文】では、旧実装について「図4のソースコードでは文字列を配列として取り扱っていたので領域の境界をプログラムで管理する必要があった」と明示しています。
• その後の改修方針として「標準C++ライブラリの文字列クラスを使用してパーセントエンコード関数を作り直す」と記述し、図5で関数シグニチャを「string urlPercentEncodeString(string src)」へ変更しています。
• さらに、「図6のソースコードではcので、バッファオーバフローが発生することはなくなった。」と背景を説明しています。
• 文字列クラス string は格納領域の確保・拡張・終端管理を処理系（ライブラリ）が自動で行います。利用側は push_back などのメンバ関数を呼ぶだけで済み、配列添字演算で自力管理する必要がありません。
• したがって、改修後は「領域の境界」を開発者が意識せずに済み、配列境界を越えて書込む不具合——すなわちバッファオーバフロー——が構造的に除去されるため、c には「文字列をstringクラスとして取り扱っており、領域の境界は処理系が管理することとなる」が入ります。

誤りやすいポイント

• 「イテレータを使えば安全」と早合点し、根本理由を“イテレータ”に求めてしまう。安全性を担保しているのは string が内部でサイズ管理している点です。
• 「push_back も配列添字と同じ書込み」と誤解し、push_back でも境界チェックがないと思い込む。string は必要に応じて自動で再確保します。
• 「UTF-8 化や128バイト制限があるから安全」と問題の主旨を取り違える。今回の質問はバッファオーバフロー防止の技術的根拠を問うています。

FAQ

解答の論理構成

1. 原因となった実装の確認
   • 図４では char *dst をはじめとする生ポインタと配列添字で文字列を扱っています。典型例が
     dst[dstPos++] = src[srcPos++];（図４ 14行目）です。
   • その結果、パーセントエンコードで１文字が３文字に増える場面などでバッファ境界を越え、フラグ変数まで上書きするバッファオーバフローが発生しました。
2. 再発防止のために盛り込まれたルール
   • 図７「文字列処理を行う場合、文字列を格納するための d の使用を禁止する。」
     → 生ポインタや配列ではなく安全なクラス（string など）を使わせる意図なので「文字型の配列」が妥当です。
   • 図７「配列又はポインタに添字を指定して書込みを行う場合、e を毎回実施する。」
     → 越境を防ぐためには必ず境界確認が必要ですから「上限チェック」。
   • 図７「引数としてポインタを受け取った場合、添字指定での f は禁止する。」
     → ポインタ経由での書込みが事故を誘発するので、添字付きで“読む”のは許容し、“書く”＝「代入」を禁止するという文脈です。
3. 以上より
   • d：文字型の配列
   • e：上限チェック
   • f：代入

誤りやすいポイント

• 「d」を“Ｃ文字列”と書くと配列でなくリテラルを含む概念になり不適切です。
• 「e」を“長さ確認”や“バウンダリチェック”とすると原文のニュアンスとずれ、８字以内要件も満たしにくくなります。
• 「f」を“アクセス”と誤答すると「読み」も含めて全面禁止と解釈され、問題文の意図（書込み禁止）と食い違います。

FAQ