バッファオーバーフロー
プログラムが、決まった大きさのメモリの領域（バッファ）に、その大きさを超えるデータを書き込み、隣の領域を壊してしまう脆弱性です（英語では buffer overflow。「バッファーオーバーフロー」とも書く）。悪用されると、プログラムが止まるほか、外部から任意のコードを実行される（
リモートコード実行）ことがあります。CISSP では
CISSPドメイン8 ソフトウェア開発のセキュリティで扱う
脆弱性の一つです。
定義
MITRE の CWE（ソフトウェアの弱点の分類）は、関係する弱点を次のように定義しています。
- CWE-120（古典的なバッファオーバーフロー）：入力のバッファの大きさが、出力のバッファの大きさより小さいことを確かめずに、入力を出力へ写す
- CWE-787（範囲外への書き込み）：意図したバッファの終わりより後ろ、または始まりより前にデータを書き込む
MITRE の CWE Top 25（最も危険なソフトウェアの弱点の一覧、2025年版）では、CWE-787 が5位、CWE-120 が11位です。スタック型（CWE-121）が14位、ヒープ型（CWE-122）が16位で、CWE-120・121・122 は、2024年版の一覧には入っていませんでした。
どこで起きやすいか
CWE-787 は、緩和策の一つとして、この弱点が起きない、または避けやすい言語を選ぶことを挙げ、処理系がメモリを自動で管理する言語（Java や Perl など）の多くはバッファオーバーフローの対象にならないとしています。逆に言えば、プログラムがメモリを直接扱う言語（C や C++ など）で書かれた部分で起きやすい弱点です（筆者の整理）。安全な言語で書いていても、ネイティブのコードとつなぐ部分では起きうると CWE-787 は注意しています。
違い・誤解しやすい点
- 「保護機能を有効にすれば防げる」：CWE-787 は、コンパイラの検出の仕組みや、メモリの配置を毎回変える仕組み（ASLR、PIE）などを、多層防御（複数の守りを重ねること）の手段として挙げています。攻撃を難しくしたり、検出したときにプログラムを止めたりするもので、弱点そのものを無くすものではありません。止まることで、サービスが使えなくなることもあります
- 「文字列の扱いに注意すれば十分」：CWE-787 は、バッファオーバーフローの多くは文字列と関係しないとしています
- [[リモートコード実行]]との関係：リモートコード実行は、バッファオーバーフローなどの弱点が悪用された結果の一つです
守る手段
CWE の緩和策を、根本の対策から多層防御の順に並べた筆者の整理です。
| 順 |
手段 |
内容 |
| 1 |
メモリ安全な言語を選ぶ |
CWE-787 は、言語の選択を緩和策の一つに挙げている。米国の CISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）などは、製品の作り手がメモリ安全な言語への移行の計画（ロードマップ）を作り公開するための手順を示した手引き（2023年12月）と、メモリ安全な言語の導入の障害を整理した手引き（NSA と共同、2025年6月）を出している |
| 2 |
書き込む前に、大きさと境界を確かめる |
CWE-120 は、実装の段階の緩和策として、確保したバッファが指定した大きさを本当に持つかを確かめ直すこと、写す量を指定する関数では、写し先と写し元が同じ大きさだと文字列の終わりの印（NUL）が付かないことがあると注意すること、ループの中でバッファに触れるときは境界を確かめることなどを挙げている |
| 3 |
検証された安全なライブラリを使う |
文字列の扱いなどで、この弱点を起こしにくい関数を使う。ただし、これだけでは足りない（CWE-787） |
| 4 |
コンパイラや OS の保護機能を有効にする |
コンパイラの検出の仕組み、ASLR や PIE などを有効にする。多層防御の手段で、完全な対策ではない（CWE-787） |
| 5 |
修正を当てる |
製品の脆弱性として見つかったものは、提供者の修正を適用する（脆弱性管理） |
関連するページ
出典
確認日：2026年10月18日
最終更新：2026年10月18日 18:18
