IT用語集 2024/12/11

境界外書き込みとは？ 10分でわかりやすく解説

コラム

境界外書き込み（Out-of-bounds Write）は、プログラムが確保したメモリ領域の外側にデータを書き込んでしまう不具合です。単なるクラッシュで終わる場合もありますが、条件がそろうと任意コード実行や権限昇格につながります。対策はコード修正だけでは足りません。境界を越えない設計、検出しやすい検査、悪用しにくくする緩和策、依存ライブラリの更新まで含めて組み立てます。

境界外書き込みとは何か

境界外書き込みとは、配列、バッファ、構造体の一部など、あらかじめ使ってよいサイズが決まっているメモリ領域の外側に書き込んでしまう状態です。CWEでは、意図したバッファの末尾より後ろ、または先頭より前に書き込む弱点として整理されています。代表例としては、バッファオーバーフローやヒープオーバーフローがあります。

どのように起きるか

発生の起点は一つではありません。多いのは、サイズ計算の誤り、配列インデックスの検証漏れ、文字列コピー時の上限未確認、可変長データの見積もり違いです。特に、HTTP、ファイル、画像、圧縮データ、プロトコルメッセージ、API入力のように外部データがそのまま内部処理へ流れ込む箇所は、攻撃者が再現条件を作りやすくなります。

起き方	想定より長い入力をそのままコピーする、長さ計算を誤る、負の値や極端に大きい値を見落とす、といった実装で発生します。
壊れる対象	隣接する変数、オブジェクト管理情報、関数ポインタ、ヒープ管理情報などが破壊されることがあります。
脆弱性になる条件	外部入力で再現でき、攻撃者が入力値やタイミングをある程度制御できる場合、単なるバグではなく悪用可能な脆弱性になります。

起こりやすい実装領域

CやC++のようにメモリ境界の扱いを開発者側で担う場面では露出しやすくなります。ただし、言語だけで決まるわけではありません。安全側の抽象化がある環境でも、ネイティブコード、拡張モジュール、画像・動画デコーダ、圧縮処理、ドライバ、古いライブラリに依存する部分では同種の問題が残ります。

何が危険なのか

境界外書き込みの影響は、止まるだけの障害から侵害インシデントまで幅があります。どこが壊れるかで被害の性質が変わります。

異常動作	別の変数や状態が壊れ、想定していない分岐、誤った権限判定、誤処理が発生します。
サービス停止	プロセスがクラッシュし、再起動ループや応答不能に至ることがあります。結果としてDoS攻撃と同じような可用性低下を招く場合があります。
任意コード実行	書き込み先を攻撃者が実質的に制御できる場合、実行フローが乗っ取られ、プロセス権限で不正な処理を動かされるおそれがあります。
権限昇格	高権限のサービスやOSに近い層で起きると、侵害範囲が一気に広がります。

情報漏えいとの違い

情報漏えいは、典型的には境界外読み取りで起こりやすい被害です。一方、境界外書き込みは、改ざん、停止、乗っ取りの方向に出やすい弱点です。ただし、認可情報や設定値が壊れた結果として、間接的に情報事故へ発展することはあります。

どの開発箇所から優先して点検するか

すべてのコードを同じ密度で点検するより、外部入力に近く、サイズ計算が複雑で、失敗時の影響が大きい箇所から着手した方が効率は上がります。優先度が高いのは次のような領域です。

ファイルパーサ、画像・動画デコーダ、圧縮・展開処理
ネットワークプロトコル処理、公開API、外部入力を受けるフォーム
独自のメモリコピー、文字列連結、シリアライズ処理
認証、認可、権限管理の近くで動くコード
古いネイティブライブラリや更新が止まった依存コンポーネント

外部公開面に近い箇所と、高権限で動く箇所が重なる場合は、最優先で潰す対象になります。

境界外書き込み対策

1. 境界を越えない設計に直す

根本対策は、入力サイズと書き込み先サイズの関係を曖昧にしないことです。受け入れる最大サイズを仕様として決め、長さ計算を一箇所に集約し、配列インデックスの範囲を毎回確認します。文字列処理では、宛先容量、書き込み予定量、終端文字分を別々に扱う設計にしておくと、オフバイワンや計算漏れが減ります。

「危険APIを避ける」だけでは不十分です。長さ引数付きの関数へ置き換えても、長さ計算そのものが誤っていれば境界外書き込みは起きます。入力値、要素数、バイト数、符号付き・符号なし整数の変換をまとめて確認する必要があります。

2. 実装を検出しやすい形にする

レビューだけでは取りこぼしが出やすいため、検査を前提にした開発フローへ寄せます。静的解析で危険な書き方を早い段階で拾い、テスト環境ではAddressSanitizerやUndefinedBehaviorSanitizerのような検査ビルドを使い、実行時に異常を顕在化させます。入力点が多いプロダクトでは、ファジングの投資対効果が高くなります。

3. 緩和策で悪用しにくくする

ASLR、DEP、スタック保護、制御フロー保護は、境界外書き込みそのものを消す仕組みではありません。それでも、実行フローの乗っ取りやコード実行の難度を上げる意味はあります。運用上は「根本修正の代わり」ではなく、「修正までの防御層」として扱うのが妥当です。

本番ビルドでは、コンパイラのハードニングオプションやOSの保護機能を有効にし、無効化している例外設定が残っていないかも確認します。ネイティブコードを含む製品では、この差が悪用難度に直結します。

4. 依存ライブラリと運用を切り離さない

自社コードを直しても、外部ライブラリに同種の不具合があれば侵入口は残ります。依存関係を把握し、SBOMや脆弱性情報と照合して更新判断ができる状態を作ります。緊急時には、機能の一時停止、入力制限、公開面の遮断、WAFによる暫定ルール追加などで露出面を狭め、その間に恒久修正を進めます。

暫定回避はあくまで時間を稼ぐ手段です。恒久対応としては、修正コードの展開、再発防止テストの追加、原因となった設計や規約の見直しまで行って初めて閉じます。

まとめ

境界外書き込みは、メモリの境界管理を誤ったときに起きる不具合で、停止、改ざん、任意コード実行、権限昇格につながり得ます。押さえるべき軸は四つです。第一に、長さと範囲の設計を曖昧にしないこと。第二に、静的解析、検査ビルド、ファジングで早く見つけること。第三に、ASLRやDEPなどで悪用難度を上げること。第四に、依存ライブラリの更新と公開面の暫定防御を運用に組み込むことです。