バッファオーバーフローとは？攻撃の仕組み・種類・具体的な対策を解説

2026年6月7日2026年7月7日

サイバー攻撃の手口は年々巧妙化していますが、バッファオーバーフローはその中でも長い歴史を持ちながら、いまなお現役の脅威であり続けています。

1988年のMorrisワームによる大規模感染、2003年のSQL Slammer、Facebookが一時サービス停止に追い込まれた事例まで、時代を問わずシステムの根幹を揺るがしてきた攻撃手法です。

「古典的な脆弱性だから自社には関係ない」と思っていると危険です。IPAの届出情報によれば、バッファオーバーフローに関連する脆弱性は現在も報告が続いており、特にC言語やC++で書かれたレガシーシステムを抱える組織では潜在的なリスクが残っています。

この記事では、バッファオーバーフローの仕組みをメモリ構造から丁寧に解説し、攻撃の種類と実際の被害事例、そして開発者・利用者それぞれが取れる実践的な対策までを体系的にまとめています。

バッファオーバーフローとは

バッファオーバーフローとは、プログラムがメモリ上に確保した「バッファ（緩衝領域）」の上限を超えてデータを書き込んでしまう現象です。日本語に直訳するなら「緩衝領域のあふれ」であり、これ自体はプログラムのバグに過ぎません。しかし、攻撃者がこの挙動を意図的に引き起こすと、システム上の任意コードを実行させる深刻なセキュリティインシデントに発展します。

少し具体的に考えてみましょう。あるWebフォームが「ユーザー名は20文字まで」という仕様で設計されているとします。しかし、その入力値の長さを検証するコードが不十分だと、攻撃者が100文字のデータを送り込んだ場合でもプログラムはそのまま受け取り、隣接するメモリ領域へデータが流れ込みます。その「はみ出た領域」に悪意あるコードが仕込まれていれば、プログラムは本来の動作とまったく異なる命令を実行してしまうわけです。

バッファとは何か

バッファとは、データを一時的に格納するためにメモリ上に確保された領域のことです。ファイルの読み込み、ネットワーク通信、フォームの入力値の受け取りなど、プログラムがデータを処理するあらゆる場面でバッファは使われています。

C言語では char name[20]; のように配列を宣言することでバッファを確保しますが、この宣言は「20バイト分の領域を用意した」に過ぎません。20バイトを超えるデータが書き込まれてもコンパイラは自動的に止めてくれないため、プログラマ自身が入力長の検証コードを書く必要があります。この確認処理が欠けているか不十分なコードが、バッファオーバーフローの温床になります。

なぜC言語はこのような設計になっているのでしょうか。もともとC言語はOSやシステムソフトウェアをハードウェアに近いレベルで制御するために設計された言語であり、実行速度とメモリ効率を最大化することが優先されました。安全性の担保はプログラマの責任とされており、境界チェックをランタイムが自動で行う仕組みは意図的に省かれています。この設計思想が現代においてセキュリティ上の弱点として顕在化しているわけです。

DoS攻撃との違い

バッファオーバーフロー攻撃はしばしばDoS（サービス拒否）攻撃と混同されますが、本質的に異なる攻撃です。

DoS攻撃はサーバーに大量のリクエストを送りつけてリソースを枯渇させ、正規ユーザーがサービスを利用できなくする「妨害行為」です。対してバッファオーバーフロー攻撃は、プログラムの動作そのものを乗っ取ることを目的とします。攻撃が成功した場合、システムをクラッシュさせるだけでなく、攻撃者が管理者権限を取得してサーバーを自由に操作できる状態になりえます。

結果としてサービスが停止することもあるため「DoS的な影響」は生じますが、バッファオーバーフローがより危険なのは、システムの乗っ取りという能動的な侵害を可能にする点です。DoS攻撃を「玄関を塞ぐ嫌がらせ」とするなら、バッファオーバーフロー攻撃は「鍵を複製して侵入する不法侵入」に近いと言えます。

バッファオーバーフロー攻撃の仕組み

攻撃がどのように機能するかを理解するには、コンピューターのメモリ管理の仕組みを知っておく必要があります。

プログラムが実行されると、OSはメモリ上にいくつかの領域を割り当てます。コードが格納される「テキスト領域」、グローバル変数が置かれる「静的（BSS）領域」、実行中の関数情報が積み上がる「スタック領域」、そして動的にメモリを確保する「ヒープ領域」です。

スタック領域には関数の引数、ローカル変数、そして「関数の処理が終わったあとにどこへ戻るか」を示す「リターンアドレス」が格納されます。このリターンアドレスこそが、スタックベースのバッファオーバーフロー攻撃において攻撃者が書き換えを狙う重要な値です。

ローカル変数として宣言されたバッファに上限を超えたデータを書き込むと、隣接するメモリ上のリターンアドレスが上書きされます。攻撃者はこのアドレスを、自ら仕込んだ悪意あるコード（シェルコードと呼ばれることが多い）の先頭アドレスに書き換えます。関数が終了するとプログラムはリターンアドレスが示す場所へジャンプし、結果として攻撃者のコードが実行されます。

では、実際の攻撃ではどうやってシェルコードをプロセスのメモリ内に置くのでしょうか。古典的な手法では、書き込む長いデータの末尾部分にシェルコード自体を埋め込み、バッファの直前の領域に配置します。さらに「NOPスレッド」と呼ばれる「何もしない命令（NOP）」を大量に並べることでシェルコードへのジャンプを成功させやすくするテクニックも知られています。攻撃者は正確なアドレスを知らなくてもNOP列のどこかにジャンプすれば最終的にシェルコードへたどり着けるため、攻撃の成功率が高まります。

バッファオーバーフロー攻撃の種類

攻撃が狙うメモリ領域によって、大きく三種類に分類できます。

スタックを標的とした攻撃

最も古典的で研究が進んでいるのがスタックベースの攻撃です。スタックは「後入れ先出し（LIFO）」構造でデータを管理しており、関数呼び出しのたびにリターンアドレスや変数が積まれていきます。

前述のようにリターンアドレスを書き換える手法は「スタックスマッシング」とも呼ばれ、1988年のMorrisワームがこの手法でfingerdデーモンを攻撃したことが記録に残っています。現代の多くのOSやコンパイラはスタックへの対策機能を持っていますが、古いシステムや設定が不十分な環境では依然として有効な攻撃手段です。

また、スタック攻撃の発展形として「Return-to-libc攻撃」があります。NXビットやDEPによってスタック上でのシェルコード直接実行が防がれるようになると、攻撃者は発想を変えました。シェルコードを自分で書き込むのではなく、すでにメモリ上にロードされているlibcライブラリの system() 関数などを呼び出すようにリターンアドレスを書き換える手法です。正規のライブラリ関数を悪用するため、実行権限の制限だけでは防ぎきれません。

ヒープを標的とした攻撃

ヒープ領域は malloc() や new 演算子で動的に確保されるメモリ領域です。スタックと違ってリターンアドレスは格納されていませんが、ヒープ上には関数ポインタやオブジェクトのメタデータが置かれることがあります。

ヒープベースの攻撃では、これらの管理情報を上書きすることで任意のコード実行を目指します。スタックに比べて複雑な条件が必要ですが、スタック保護機構が普及した現代においてより多く見られるようになった手法です。2000年代以降の研究ではヒープスプレーと呼ばれる技術も開発されており、メモリの広い範囲にシェルコードを配置することで攻撃成功率を高めています。

ヒープ攻撃が難しいとされる理由は、ヒープのレイアウトが実行時の状況によって変化するため、書き換えるべきアドレスを特定しにくい点にあります。しかし逆に言えば、ヒープ攻撃に成功するほどの技術を持つ攻撃者は高度な知識を持っており、標的型攻撃のような文脈で利用されるケースが多いとも言えます。

静的領域を標的とした攻撃

静的領域にはグローバル変数や静的変数が格納されています。この領域はプログラムの実行中を通じてアドレスが固定されているため、攻撃者が値を上書きしやすいという特性があります。グローバルな関数ポインタや認証フラグを書き換えることで、権限チェックをバイパスするといった攻撃に悪用されます。

スタックやヒープと比較すると注目されることが少ない領域ですが、グローバルスコープで宣言されたバッファへの入力検証漏れは実際のコードでも珍しくありません。特にレガシーなC言語のコードベースでは静的配列を多用している場合があり、見落とされがちなリスクポイントです。

バッファオーバーフロー攻撃を受けた場合の被害

攻撃が成功した場合の被害は、単純なサービス停止にとどまりません。

管理者権限の奪取が最も深刻なシナリオです。Webサーバーやデータベースサーバーが管理者権限で動作している場合、攻撃者はそのサーバー上で任意のコマンドを実行できるようになります。機密情報の窃取、データの改ざん・削除、ランサムウェアの展開、マルウェアのインストールなど、その後の攻撃は無限に広がります。

特に問題なのは、バッファオーバーフローによる権限奪取が「痕跡を残しにくい」点です。正規のプロセス内で悪意あるコードが実行されるため、セキュリティ監視ツールが不審なプロセスとして検知しにくい状況が生まれます。侵害が発覚するのが数週間・数ヶ月後になることも珍しくなく、その間に情報が流出し続けるというシナリオが現実に起きています。

踏み台としての悪用も見逃せない被害形態です。侵害されたサーバーは攻撃者の支配下に置かれ、他の組織へのサイバー攻撃の中継地点として利用されます。被害者であるはずの組織が加害者として認識されるリスクがあり、法的・倫理的な問題にも発展しかねません。実際、国内の自治体や企業サーバーが攻撃の踏み台に使われた事例は複数記録されており、サービス停止という目に見える被害がなくても、こうした「見えない被害」が進行していることがあります。

バッファオーバーフローの被害事例

バッファオーバーフローは過去の話ではありません。記録に残る主な事例を見ていきましょう。

官公庁のWebサイト改ざん

国内では、官公庁や自治体のWebサイトがバッファオーバーフローの脆弱性を突かれてコンテンツを改ざんされた事例が複数報告されています。これらのケースでは、Webサーバーのアプリケーション層に存在した脆弱性が悪用され、一般市民が閲覧する公式情報に不正なコンテンツが埋め込まれました。公的機関への信頼を損なうという意味でも、社会的影響は大きなものでした。改ざんされたページを経由してマルウェアが配布されるケースもあり、訪問者が二次被害を受けるリスクも伴っていました。

Facebookのサービス停止

Facebookは2007年にバッファオーバーフローに起因するサービス障害を経験したことが知られています。同社の規模のサービスが一時的にでも停止した事実は、バッファオーバーフローが世界規模のインフラにも影響を及ぼしうることを示す象徴的な事例として語り継がれています。数億人規模のユーザーを抱えるプラットフォームであっても、低レイヤーのメモリ管理の問題からは無縁ではないことを示した出来事でした。

大手ソフトウェア製品における脆弱性

Microsoft、Adobe、Oracle、OpenSSLなど、広く使われているソフトウェアにも過去にバッファオーバーフロー脆弱性が見つかっています。CVE（共通脆弱性識別子）データベースを参照すると、これらの製品に対するパッチは現在も定期的に提供されており、決して過去に終わった問題ではないことがわかります。

特に注目すべきはOpenSSLのHeartbleed脆弱性（CVE-2014-0160）です。これはバッファオーバーフローの一種で、攻撃者がサーバーのメモリから秘密鍵や認証情報を読み取れる状態になっていました。世界中のHTTPS通信の多くがOpenSSLに依存していたため、被害の潜在的な規模はほぼ「インターネット全体」と表現されるほどでした。OpenSSLは世界中のセキュリティ専門家が目を通していたはずのコードベースであり、それでも長年にわたって見逃されていた事実は、バッファオーバーフロー検出の難しさを端的に示しています。

バッファオーバーフロー攻撃への対策

対策は「開発者側」と「利用者（運用）側」で考えると整理しやすいです。

開発者側の対策

1. 直接メモリ操作ができない言語を選ぶ

バッファオーバーフローが発生しやすいのは、C言語やC++のようにメモリを直接操作できる言語です。Java、Python、Ruby、Go、Rustなど、メモリ管理を言語ランタイムが担う言語で実装すれば、同種の脆弱性のリスクは大幅に低減できます。ただし、既存のレガシーシステムを完全に書き換えるのは現実的ではないため、新規開発と既存システムの対策を分けて考える必要があります。

特筆に値するのがRustです。Rustはコンパイル時にメモリ安全性を検証する独自の「所有権システム」を持っており、バッファオーバーフローを含む多くのメモリ関連バグをコンパイル段階で検出できます。Microsoftや米国国家安全保障局（NSA）が安全なシステムプログラミング言語としてRustへの移行を推奨していることは、セキュリティコミュニティでよく知られた事実です。AndroidカーネルへのRust採用やLinuxカーネルへの段階的な導入も進んでおり、業界全体としてC言語から距離を置こうとする動きは加速しています。

2. 入力データの長さを必ず検証する

C言語で開発する場合は、文字列操作関数の使い方に細心の注意が必要です。gets() や strcpy() のような「コピー先バッファのサイズを考慮しない」関数は使用禁止と考えてください。代わりに fgets() や strncpy() のようなサイズ指定ができる関数を使い、バッファ長を超えた入力を切り捨てるか拒否する処理を必ず実装します。

scanf() も脆弱性の温床になりやすい関数です。フォーマット文字列に %s を使う場合、%20s のように最大入力文字数を指定することで対策できますが、これを徹底するにはコードレビューの文化と静的解析ツールの導入が欠かせません。

入力検証のポイントは「上流で一度だけ行う」ことです。複数箇所で同じ検証を分散して行うと、修正や追加のたびにすべての箇所を更新しなければならず、漏れが生じやすくなります。入力が外部から入ってくる境界点に検証処理を集中させ、内部モジュールは「渡ってきたデータは検証済み」という前提で動作する設計が、長期的なメンテナンス性とセキュリティの両立につながります。

3. 脆弱性が修正されたライブラリを使用する

ゼロから実装するより、実績あるライブラリを使うほうがセキュリティ品質は高い場合がほとんどです。ただし、ライブラリ自体に脆弱性が潜むケースも多く、使用しているライブラリのCVE情報を定期的に確認し、セキュリティパッチが出たら速やかに適用する運用体制が必要です。

4. コンパイラのセキュリティ機能を活用する

現代のコンパイラはバッファオーバーフロー対策機能を備えています。代表的なものを挙げると次のとおりです。

SSP（Stack Smashing Protector、カナリア）: スタックの重要な値の前に「カナリア値」を配置し、関数の終了時にその値が変化していないかを確認します。変化があればバッファオーバーフローが発生したと判断し、プログラムを強制終了します。GCCでは -fstack-protector-strong オプションで有効化できます。
ASLR（Address Space Layout Randomization）: プログラムの実行ごとにスタックやヒープのアドレスをランダム化します。攻撃者がシェルコードのアドレスを予測しにくくなるため、リターンアドレスの書き換えが成功しても悪意あるコードへジャンプできない確率が高まります。
NX（No-eXecute）ビット / DEP（Data Execution Prevention）: データ領域（スタックやヒープ）に書き込まれたコードを実行不可能にする機能です。シェルコードをバッファに書き込んでも実行されないため、古典的なスタックバッファオーバーフロー攻撃への有効な防御となります。

これらの機能はデフォルトで有効になっていることも多いですが、ビルド設定を確認し、意図せず無効化されていないかチェックする習慣が重要です。なお、ASLR単体では完全な防御にはなりません。情報漏洩（information leak）と組み合わせた攻撃でアドレスを特定されるケースも報告されており、多層的な防御の一要素として位置づける必要があります。

5. 静的コード解析の導入

人間によるコードレビューだけでは見落としが生じます。静的解析ツールをCI/CDパイプラインに組み込み、危険な関数の使用や境界チェック漏れを自動的に検出する体制を整えてください。C/C++向けの静的解析ツールとしてはCppcheckやClang Static Analyzerなどが広く使われています。ファジング（fuzz testing）も有効なアプローチで、ランダムまたは意図的に異常な入力を大量に与えることでバッファオーバーフローを引き起こしうる箇所を実行ベースで発見できます。GoogleのOSS-Fuzzプロジェクトはオープンソースプロジェクトへのファジングを継続的に行っており、実際に多くのバッファオーバーフロー脆弱性がこの手法で発見されています。

利用者（運用・管理者）側の対策

OSおよびミドルウェアのアップデートを怠らない

既知の脆弱性に対するパッチが公開されても、適用までに時間がかかる組織は少なくありません。パッチ適用のワークフローを整備し、重大な脆弱性は緊急対応できる体制を維持することが基本中の基本です。特にCVSSスコア（共通脆弱性評価指標）が高い脆弱性は公開直後に攻撃が試みられるケースもあり、「パッチが出たら翌月の定例メンテナンスで適用」という運用では対応が遅すぎる場面があります。

WAF（Webアプリケーションファイアウォール）の導入

WAFはWebアプリケーション宛ての通信を監視し、バッファオーバーフローを引き起こしうる異常な長さの入力値や不審なパターンを持つリクエストを遮断します。アプリケーション側の修正が完了するまでの暫定対策としても有効ですが、WAFはあくまで多層防御の一要素として位置づけてください。WAFのシグネチャは常に最新の状態に保つことが重要で、更新を怠ると新たな攻撃手法に対応できなくなります。

Webアプリケーション脆弱性診断の実施

ペネトレーションテストや脆弱性診断を定期的に実施することで、実際に悪用される前にバッファオーバーフローを含む脆弱性を洗い出せます。特に外部公開されているシステムや、アップデートが行われていないレガシーシステムは優先的に診断対象とすべきです。自動スキャンツールだけでなく、熟練したセキュリティエンジニアによる手動診断を組み合わせることで、ツールが見落とすロジックレベルの脆弱性まで検出できます。

開発者が実務で意識すべき視点

セキュリティ対策の教科書には「入力値を検証せよ」と書かれています。しかし実際の開発現場では、「どこで」「どの程度の厳格さで」検証を行うかの設計判断が難しいことが多いです。

一つの原則として有効なのが「入力の信頼境界を明確にする」という考え方です。外部から来るデータ（ユーザー入力、ファイル、ネットワークパケット、外部APIのレスポンスなど）はすべて「信頼できないデータ」として扱い、内部の処理に渡す前に必ず検証・サニタイズします。この考え方を徹底するだけで、バッファオーバーフローのみならず多くの脆弱性のリスクを下げられます。

もう一点、見落とされがちなのが「ライブラリに潜むバッファオーバーフロー」です。自分のコードに危険な関数を使っていなくても、依存するライブラリの内部で問題が発生することがあります。2014年のOpenSSLにおけるHeartbleed脆弱性はその典型例で、バッファの境界チェックが不適切だったことが原因でした。SBOMを管理し、サプライチェーン全体の脆弱性を追跡することが、現代のセキュリティ運用では求められています。

さらに実務的な観点から言えば、「セキュアコーディング規約の整備」と「開発チームへの教育」がもっとも費用対効果の高い対策の一つです。ツールや機能に依存するだけでなく、開発者一人ひとりがバッファオーバーフローの発生原理を理解したうえでコードを書く文化を根づかせることが、長期的な脆弱性低減につながります。コードレビューのチェックリストにバッファサイズの検証を明示的に含めるだけでも、見落としのリスクは大きく下がります。