緊急度：高
主要マザーボードメーカー製品にPre-Boot DMA Protection無効化の脆弱性。至急BIOSアップデートを推奨。
はじめに
2025年12月、Riot Gamesのアンチチート「Vanguard」チームが、複数の主要マザーボードメーカーのファームウェアに致命的なセキュリティ欠陥を発見しました。この脆弱性により、BIOSで保護機能が有効と表示されていても、実際にはIOMMUが正しく初期化されず、DMA攻撃による検知不可能なコード注入が可能になります。
対象読者
セキュリティエンジニア、インフラエンジニア、ゲーム開発者、システム管理者、自作PCユーザー
この記事で得られる知識:
- IOMMU/Pre-Boot DMA Protectionの仕組みと脆弱性の技術的詳細
- ブート時のセキュリティチェーンとDMA攻撃の関係性
- 各マザーボードメーカーのCVE情報と具体的対策手順
- システムセキュリティの根本的な課題への理解
参考資料: Vanguard Security Update: Closing the Pre-Boot Gap - Riot Games
TL;DR（結論を先に知りたい方へ）
クリックして展開
発見された脆弱性
- Pre-Boot DMA ProtectionがBIOSで「有効」と表示されていても、実際にはIOMMUが正しく初期化されない
- ブート初期の数秒間、DMAデバイスが無制限にメモリアクセス可能な状態
- この隙間を突くことで、OS起動前に検知不可能なコードを注入できる
影響を受けるシステム
| メーカー | CVE番号 | 影響範囲 |
|---|---|---|
| ASUS | CVE-2025-11901 | 複数モデル |
| Gigabyte | CVE-2025-14302 | 複数モデル |
| MSI | CVE-2025-14303 | 複数モデル |
| ASRock | CVE-2025-14304 | 複数モデル |
対策
最新のBIOSファームウェアへの更新が必須（詳細は後述）
DMA攻撃とは - なぜこれほど危険なのか
DMAの仕組みと特権性
DMA（Direct Memory Access）は、デバイスがCPUを経由せず直接メモリにアクセスできる機構です。通常は高速なデータ転送のために使用されますが、悪用されると以下のようなリスクがあります。
DMA攻撃の危険性
- OSのセキュリティポリシーをバイパスしてメモリを直接操作
- パスワード、認証情報、暗号鍵などの機密情報を窃取
- カーネルメモリの改変による完全なシステム制御
DMAチートの脅威
ゲーム業界では、PCIeスロットに挿入するDMAカードを使ったチートが最も高額で効果的な手法とされてきました。これらは通常のメモリスキャンやコード解析では検知不可能です。
通常のチート: ゲームプロセス内で動作 → 検知可能
DMAチート: ハードウェアレベルでメモリ直接操作 → 検知困難
DMA攻撃の具体例（Thunderclap攻撃）
2019年に発見されたThunderclap攻撃では、Thunderboltポート経由でPCのシステムメモリを直接読み書きできることが実証されました。macOS、Windows、Linux、FreeBSDの全てが影響を受け、接続から数秒でシステム全体が侵害可能でした。IOMMU保護の実装不備が原因です。
IOMMUによる防御メカニズム
IOMMUの役割
IOMMU（Input-Output Memory Management Unit）は、DMA攻撃に対する防御の要です。デバイスごとにメモリアクセス権限を管理し、許可されていないメモリ領域へのDMAアクセスをブロックします。
┌─────────────────┐
│ DMAデバイス │
└────────┬────────┘
│
[アクセス要求]
│
▼
┌─────────┐
│ IOMMU │ ← "メモリのバウンサー"
└────┬────┘
│
[許可/拒否]
│
▼
┌─────────┐
│ メモリ │
└─────────┘
Pre-Boot DMA Protectionとは
Windows 10/11では、Kernel DMA Protection（Pre-Boot DMA Protection）という機能が実装されています。この機能は、UEFI起動時からIOMMUを有効化し、OSが起動する前からDMA攻撃を防御します。
Pre-Boot DMA Protectionの目的
UEFI起動時からIOMMUを有効化することで、OSが起動する前からDMA攻撃を防御し、特にThunderboltポートなど高速DMAデバイスに対する保護を提供します。
理論上は、この機能によりブート初期からシステムは保護されるはずでした。
発見された致命的な欠陥 - "眠っているバウンサー"
脆弱性の本質
Riot Vanguardチームの調査により、以下の事実が判明しました。
発見された問題点
- BIOSで「Pre-Boot DMA Protection: Enabled」と表示
- しかし実際にはIOMMUが正しく初期化されていない
- ファームウェアがOSに対して「保護が有効」と誤ったシグナルを送信
この状態は、まさにバウンサーが椅子で眠っている状態です。OSは保護されていると信じているが、実際には無防備という状況です。
攻撃可能なタイミング
[電源ON] → [UEFI起動] → [IOMMU初期化"失敗"] → [OS起動] → [Vanguard起動]
↑━━━━━━━━━━ この数秒間が脆弱 ━━━━━━━━━━↑
この短い窓の間に、DMAデバイスは無制限にメモリアクセス可能で、任意のコードを注入でき、OS・Vanguard起動前に隠蔽を完了できます。
なぜ発見が困難だったか
1. OSから見ると「保護は有効」と報告される
→ システム情報を見ても異常が見当たらない
2. 通常のセキュリティ監査では検知不可能
→ ファームウェアの内部実装まで検証する必要
3. 既存のアンチチート・セキュリティソフトも無効化
→ OS起動後では既に手遅れ
Vanguardチームは、ファームウェアレベルの実装を詳細に検証することでこの問題を発見しました。
影響を受けるマザーボードと対策
公開されたCVE情報
各メーカーは迅速にセキュリティアドバイザリを公開しました。
| メーカー | CVE番号 | セキュリティアドバイザリ | 対応状況 |
|---|---|---|---|
| ASUS | CVE-2025-11901 | ASUS Security Advisory | 対応済 |
| Gigabyte | CVE-2025-14302 | Gigabyte Security Advisory | 対応済 |
| MSI | CVE-2025-14303 | MSI Security Advisory | 対応済 |
| ASRock | CVE-2025-14304 | ASRock Security Advisory | 対応済 |
対策手順
ステップ1: 現在のBIOSバージョン確認
# Windows PowerShellで確認
Get-WmiObject -Class Win32_BIOS | Select-Object SMBIOSBIOSVersion, Manufacturer
# または
systeminfo | findstr /B /C:"BIOS"
# Linux環境の場合
sudo dmidecode -t bios
ステップ2: メーカーサイトから最新BIOSをダウンロード
重要な注意事項
自分のマザーボードモデル番号を正確に特定してください。間違ったBIOSファイルを使用すると起動不能になる可能性があります。ダウンロード前にチェックサムを確認することを推奨します。
各メーカーのBIOSダウンロードページ
- ASUS: ASUS サポート
- Gigabyte: Gigabyte サポート
- MSI: MSI サポート
- ASRock: ASRock サポート
製品型番で検索し、「BIOS」または「ファームウェア」セクションから最新版をダウンロードしてください。
ステップ3: BIOS更新の実施
BIOS更新時の厳重注意事項
絶対に更新中に電源を切らないこと（マザーボードが故障します）。ノートPCの場合はACアダプタを接続し、UPS（無停電電源装置）の使用を推奨します。現在の設定をBIOSプロファイルとして保存しておいてください。
1. USBメモリをFAT32でフォーマット
2. ダウンロードしたBIOSファイルをUSBメモリのルートに配置
3. PCを再起動しUEFI BIOS画面に入る（通常Del/F2キー）
4. BIOS更新機能を実行（Q-Flash, M-Flash, EZ Flash等）
5. USBメモリからBIOSファイルを選択
6. 更新完了まで待機（5-10分程度）
7. 自動で再起動するまで絶対に電源を切らない
ステップ4: セキュリティ設定の確認
更新後、以下の設定を必ず確認してください。
[ ] Secure Boot: Enabled
[ ] TPM 2.0: Enabled
[ ] VBS (Virtualization-Based Security): Enabled
[ ] Pre-Boot DMA Protection: Enabled
[ ] Intel VT-d / AMD-Vi (IOMMU): Enabled
VBS（Virtualization-Based Security）とは
VBSは、Windowsのセキュリティ機能で、ハイパーバイザーを使用してOSのセキュリティ機能を隔離します。主な機能として、Credential Guard（認証情報の保護）、Device Guard（コード整合性の検証）、HVCI（Hypervisor-Protected Code Integrity：カーネルモード保護）があります。Windows 11では標準で有効化されています。
Riot Vanguardの対応 - VAN:Restrictionシステム
制限の仕組み
Vanguardは、脆弱な設定を検出するとVAN:Restrictionを適用します。
VAN:Restrictionの特徴
アカウントまたはHWIDレベルでVALORANT起動を制限します。これは「チート使用の疑い」ではなく「セキュリティベースライン未達」という扱いであり、チーター環境との統計的類似性を検出した場合に適用されます。
制限が適用される条件は以下の通りです。
- Pre-Boot DMA Protectionが正しく動作していない
- Secure Bootが無効
- TPMが無効またはバージョン不足
- VBSが無効
- ハードウェア構成が不審（統計的異常）
制限を受けた場合の対処
- 表示される指示に従いセキュリティ機能を有効化
- BIOS更新を実施（上記手順参照）
- Windows Updateを最新に
- 問題が解決しない場合はRiot Supportに連絡
今後の展開
RiotはAscendant以上のランクでこの要件を全プレイヤーに適用することを検討中です。競技シーンの公平性を保つための措置です。
業界への影響 - ゲームを超えた重要性
セキュリティ業界全体の課題
この脆弱性は、ゲーム以外のアンチチート・セキュリティ製品すべてに影響を与える可能性がありました。影響を受ける可能性があった製品群には、EDR（Endpoint Detection and Response）製品、DLP（Data Loss Prevention）システム、企業向けセキュリティソフトウェア、他のアンチチートシステム、仮想化環境のセキュリティ機能が含まれます。IOMMUが正しく機能していなければ、これらすべての防御が無効化される可能性があります。
Microsoftの取り組み
Microsoftも同様のアプローチを推進しています。Xboxの記事「Building a Trusted Gaming Future: How Security Powers Fair Play」でも、ハードウェアベースのセキュリティ基盤の重要性が強調されています。
UEFIセキュリティの継続的な課題
UEFI Secure Bootの脆弱性も継続的に発見されています。
| CVE番号 | 内容 | 発見時期 |
|---|---|---|
| CVE-2024-7344 | Secure Bootバイパス脆弱性 | 2024年 |
| CVE-2024-23599 | Intel UEFIファームウェアの競合状態 | 2024年 |
| CVE-2025-11901 | ASUS IOMMU初期化不備 | 2025年 |
なぜファームウェアの脆弱性は発見が困難なのか
ファームウェア脆弱性の特性として、クローズドソース（ソースコードが公開されていない）、低レベルすぎて通常のセキュリティツールでは検査不可能、製造元ごとに実装が異なる、エンドユーザーがBIOS更新を避ける傾向、一度侵害されると完全な制御を奪われるといった点が挙げられます。ファームウェアレベルのセキュリティは、常に注視が必要な領域です。
まとめと今後の対応
システム管理者・エンジニアへの推奨事項
[ ] 即座に実施: マザーボードBIOSを最新版に更新
[ ] 定期的な確認: セキュリティアドバイザリの監視体制構築
[ ] 環境整備: VBS・Secure Boot・TPMの有効化
[ ] 監視強化: 不審なDMAデバイスの検出メカニズム構築
[ ] ドキュメント化: 社内のBIOS更新手順書の作成
技術的な学び
この事例から得られる教訓
- ファームウェアレベルの検証は不可欠 - OSレベルの報告を盲信せず、ハードウェアの実装まで検証する必要がある
- ブート初期のセキュリティギャップ - 最も特権的な瞬間が最も脆弱であり、Pre-Bootセキュリティの重要性が再確認された
- ハードウェア・ソフトウェアの協調 - 両方が正しく動作して初めて防御が成立し、サプライチェーン全体でのセキュリティ意識が必要