Use-After-Free（UAF）脆弱性とは？仕組み・被害例・対策をわかりやすく解説

「ブラウザを最新版に更新してください」「このゼロデイ脆弱性により任意コードが実行可能」——セキュリティニュースでよく見かけるこうした警告の背後には、”Use-After-Free”と呼ばれるメモリの脆弱性が潜んでいるケースが少なくありません。

Chrome、Firefox、Windowsカーネル、Linuxカーネルなど、普段当たり前に使っているソフトウェアでも、定期的にUAF（Use-After-Free）が原因のCVEが公開されています。「聞いたことはあるけれど仕組みがよくわからない」という方も多いこの脆弱性を、防御に活かせるレベルで解説します。

Use-After-Free（UAF）とは？

Use-After-Free（使用後解放）とは、一度「解放済み」としてマークされたメモリ領域に、その後もプログラムがアクセスし続けてしまう脆弱性です。

コンピュータのプログラムは動作中に「ヒープ」と呼ばれるメモリ領域を動的に確保・解放しながら処理を進めます。C言語やC++などの言語では、プログラマが自分でメモリの確保（malloc/new）と解放（free/delete）を管理します。

問題は、解放した後もそのメモリアドレスを指すポインタ（「ダングリングポインタ」と呼ばれます）が残っていた場合に起きます。プログラムがそのポインタを使ってメモリにアクセスしようとすると、そこにはすでに別のデータが置かれているかもしれません。あるいは、攻撃者が意図的にその解放済み領域に悪意のあるデータを配置していることもあります。

・ヒープ（Heap）: プログラム実行中に動的に確保・解放されるメモリ領域
・ダングリングポインタ: 解放済みのメモリを指したままになっているポインタ
・UAF: そのダングリングポインタを介して解放済みメモリにアクセスする操作

攻撃の仕組み（敵を知る）

1. メモリの確保・解放とポインタの関係

まず正常な動作を確認します。

# C言語でのメモリ操作（概念的な例）
char *ptr = malloc(64);    # ヒープに64バイトを確保
strcpy(ptr, "user data");  # データを書き込む
free(ptr);                 # メモリを解放する

# ここで ptr はまだ旧アドレスを指している（ダングリングポインタ）
# ptr = NULL とリセットしなければ次の操作が危険
printf("%s", ptr);         # ← UAF！解放後のメモリを読み取っている

2. 攻撃者がUAFをどう悪用するか

攻撃者がUAFを実際に悪用するまでには、大きく3つのフェーズがあります。

フェーズ1：解放を引き起こす
攻撃者は、標的プログラムに特定のオブジェクトを解放させるトリガーを送ります。Webブラウザの場合、JavaScriptで特定のDOM操作を行うことでブラウザエンジン内部のC++オブジェクトを解放させることがあります。

フェーズ2：解放された領域に悪意のあるデータを置く
OSはメモリを解放すると、その領域を「空き」としてプールに返します。攻撃者はすぐさま別のアロケーション（メモリ確保要求）を発行し、解放されたばかりの領域に攻撃者が制御するデータを配置します。これを「ヒープスプレー」「ヒープグルーミング」と呼びます。

フェーズ3：ダングリングポインタ経由でアクセスさせる
プログラムがダングリングポインタを使って旧領域にアクセスした瞬間、そこには攻撃者が仕込んだデータがあります。ここに関数ポインタや重要な制御情報が含まれていれば、任意コード実行（RCE）につながります。

3. ブラウザでの典型的なシナリオ

Webブラウザは外部から来るJavaScriptコードを実行するため、UAFの格好の攻撃対象です。攻撃者が用意した悪意のあるWebページを被害者が訪問するだけで、ブラウザ内部のUAFが引き起こされ、攻撃者のコードがブラウザのプロセス権限で実行されることがあります。

Chrome、Firefox、Edgeなどの主要ブラウザでは、毎月の定期アップデートにUAF修正が含まれていることも珍しくありません。このためブラウザの更新が遅れた環境は、公開済みのUAFを狙った攻撃にさらされるリスクが高まります。

具体的な防御手順

1. パッチを素早く適用する（最重要）

UAFは発見・修正されてから公開されるまでの間、悪用が集中します。ブラウザ・OS・ミドルウェアのセキュリティパッチを迅速に適用することが最も効果的な対策です。

# Debian/Ubuntu系：セキュリティパッチのみ自動適用
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
# /etc/apt/apt.conf.d/50unattended-upgrades で対象を確認

# Chromeのバージョン確認（Linuxデスクトップ環境）
google-chrome --version
# 管理対象端末はポリシーで自動更新を強制する

2. メモリ安全な言語への移行検討（開発者向け）

新規開発や既存コードのリファクタリングでは、GCを持つ言語やメモリ安全言語を選択することでUAFを根本から排除できます。

・Rust: コンパイル時にメモリの所有権・借用を検証し、ダングリングポインタをコンパイルエラーで防ぐ。NSA・Google・Microsoftなどもメモリ安全言語への移行を推奨している
・Go / Java / Python: GC（ガベージコレクタ）が不要になったメモリを自動解放するため、UAFは原則発生しない
・C++の場合: スマートポインタ（std::unique_ptr・std::shared_ptr）を使い、生ポインタとdeleteの手動管理を避ける

3. コンパイラ・OSレベルの緩和技術を活用する

既存のC/C++コードに対しては、コンパイラとOSが提供する緩和技術を組み合わせることで悪用の難易度を引き上げられます。

# AddressSanitizer（ASan）でビルドしてUAFを検出（開発・テスト環境向け）
gcc -fsanitize=address -g -o myprogram myprogram.c

# ASLR（アドレス空間配置のランダム化）の有効化確認
cat /proc/sys/kernel/randomize_va_space
# 2 = フルASLR有効（デフォルト）

# Valgrindのmemcheckツールで動的解析（開発・テスト環境）
valgrind --tool=memcheck --leak-check=full ./myprogram

・ASLR（Address Space Layout Randomization）: ヒープ・スタック・ライブラリの配置をランダム化し、解放済み領域のアドレス予測を困難にする。Linuxでは randomize_va_space=2 で有効
・AddressSanitizer（ASan）: ビルド時に有効化するとUAFを実行時に検出できる。本番環境には性能影響があるが、開発・CI環境での必須ツール
・Control Flow Integrity（CFI）: 関数ポインタの呼び出し先を正当なものに限定し、UAF経由で制御を奪われても任意コードの実行を困難にする
・ヒープメタデータ保護: OSやアロケータがヒープ領域のメタデータを保護し、解放済み領域への書き込みを検出する

4. 静的解析・コードレビューを活用する

開発段階でUAFの可能性がある箇所を検出することも重要です。

# Clang Static Analyzerを使った静的解析
scan-build --use-analyzer=clang make

# cppcheckによる静的解析
cppcheck --enable=all mycode.c

# free()直後のポインタをNULL化する（コーディング規約として）
free(ptr);
ptr = NULL;  # ← ダングリングポインタ解消。再アクセス時にクラッシュで検出できる

・ポインタをNULL化する習慣: free(ptr) の直後に ptr = NULL; と書く。再度アクセスするとNULLポインタ参照でクラッシュするため、UAFによるサイレントな悪用を防げる
・RAII（Resource Acquisition Is Initialization）パターン: C++でリソースの確保と解放をオブジェクトのライフタイムに紐付けることで、解放忘れ・二重解放・UAFを防ぐ

中小企業でも今日からできること

「うちはC/C++で開発していないから関係ない」と思うかもしれませんが、中小企業が使うブラウザ・OS・商用ソフトウェアにはUAFが潜んでいる可能性があります。エンドユーザー・情シスとして今すぐできることを整理します。

・ブラウザの自動更新を必ず有効にする: Chrome・Edge・Firefoxはセキュリティパッチをほぼ毎月リリースしている。管理端末ではMDMやグループポリシーで強制更新を設定する
・OSとソフトウェアのパッチ管理を徹底する: WindowsならPatch Tuesday（月例パッチ）、LinuxはCVSSスコアの高いものを優先的に適用する
・古いソフトウェアを使い続けない: サポート切れのブラウザ・OS・オフィスソフトはUAFを含む未修正の脆弱性の温床になる
・ブラウザサンドボックスを有効にする: ChromeやEdgeは複数プロセスのサンドボックスアーキテクチャを採用しており、UAFが悪用されても被害をブラウザプロセス内に封じ込める効果がある
・EDRを導入する: ブラウザ経由の悪用はファイルレスな場合も多く、EDRによるプロセスの振る舞い検知が有効な防御層になる

姉妹サイトLinuxMaster.JPでは、Linuxカーネルのメモリ保護設定やsysctlパラメータの安全な設定についても詳しく解説しています。

よくある誤解と注意点

【誤解1】UAFはCTFや研究者だけの話だ

実際にはChromeやWindowsカーネルの脆弱性として、攻撃グループによる積極的な悪用（In-the-wild exploitation）が繰り返し確認されています。特に金銭的な動機を持つグループや商業スパイウェアのベンダーにとって、ブラウザのUAFは高価値なゼロデイとして取引されています。

【誤解2】ファイアウォールがあれば防げる

UAFはネットワーク境界でブロックできるものではありません。ユーザーが正規のWebブラウザで悪意のあるページを訪問するだけで発動します。境界型防御に加えてエンドポイントのパッチ管理・EDR導入が必要です。

【誤解3】Rustに変えれば全て解決する

Rustはメモリ安全な言語ですが、unsafeブロック内ではUAFが発生する可能性があります。またサードパーティライブラリがC/C++で書かれている場合、FFI（外部関数インタフェース）経由でUAFが起きることもあります。「Rust = 完全に安全」とは言い切れず、コード品質の維持・ライブラリ管理は依然として重要です。

【注意】二重解放（Double Free）との違い

UAFと混同されやすい「二重解放（Double Free）」は、同じメモリ領域を2回 free() してしまう脆弱性です。現代のアロケータはDouble Freeを検出してクラッシュさせることが多く、UAFより悪用は難しい場合もありますが、同様に深刻です。UAFと合わせて対策します。

UAF対策の全体像まとめ

本記事のまとめ

Use-After-Free（UAF）は、解放済みメモリへの誤ったアクセスから発生するメモリ安全性の脆弱性です。主要ブラウザやOSカーネルで定期的に発見・修正されており、ゼロデイとして積極的に悪用されることもある深刻なリスクです。

・原理は「解放したポインタを使い続けること」: ダングリングポインタが攻撃の起点になる
・攻撃者は解放済み領域に悪意のあるデータを配置: ヒープグルーミングで制御フローを乗っ取る
・最も効果的な対策はパッチ管理: ブラウザとOSを常に最新に保つことが最優先
・開発者はASan・静的解析・Rust移行で根本対策: コンパイラと解析ツールを活用する
・情シスはエンドポイント対策とパッチ強制適用の仕組みを整備する: MDMやグループポリシーで人手に頼らない更新管理を

「自分たちはC言語を書いていないから」では済まない時代です。使っているすべてのソフトウェアのパッチ状況を定期的に確認するところから始めましょう。