themalwareguardian/cve-2022-34301CVE-2022-34301 の Secure Boot バイパスを、Eurosoft 署名済み UEFI Shell (esdiags.efi) 経由で実演し、mm コマンドを使って gSecurity2 を無効化し、未署名の UEFI アプリケーションをロードします。
Eurosoft Pc-Check UEFI Diagnostics Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - 署名済み UEFI Shell と gSecurity2 の破壊による Secure Boot バイパス。
このリポジトリは、CVE-2022-34301 を悪用することで BYOVUA (Bring Your Own Vulnerable UEFI Application) 技術を実演します。これは Eurosoft Pc-Check UEFI 診断環境における Secure Boot バイパス脆弱性です。
このケースでは、Secure Boot によって信頼されているコンポーネントは esdiags.efi です。これは Eurosoft の Pc-Check UEFI ハードウェア診断製品の一部として配布されている UEFI Shell であり、Microsoft の UEFI Third Party Certificate Authority によって信頼された証明書チェーンで署名されています。一度実行されると、このシェルは mm (memory modify) コマンドを公開し、それによって OS 起動前のブートフェーズにおいて 任意のメモリ読み書き 機能を提供します。
このプリミティブは、DXE コア内の gSecurity2 グローバルポインタを特定して無効化するために使用できます。その結果、以降の UEFI イメージ検証が無効化され、Secure Boot が有効であっても未署名の UEFI アプリケーションやブートキットをロードできるようになります。
BYOVUA は、カーネルレベルで使用される BYOVD (Bring Your Own Vulnerable Driver) 技術の UEFI 版です。脆弱性を持つ署名済みカーネルドライバを持ち込む代わりに、攻撃者は署名済み UEFI アプリケーション - この場合は完全な UEFI Shell - を持ち込み、Secure Boot を損なう可能性のある機能を含んでいます。
このアプリケーションは Secure Boot によって信頼された証明書チェーンで署名されているため、疑われることなく受け入れられ、Microsoft UEFI Third Party Certificate Authority を Secure Boot データベース (db) に含むあらゆるシステム - つまり過去 10 年間に出荷されたほぼすべての UEFI 対応 PC - で信頼されます。一度実行されると、その組み込みコマンドは攻撃者に直接的なハードウェアおよびメモリアクセスを提供し、それは オペレーティングシステムがロードされる前 に動作し、最新のセキュリティ制御 (ASLR、DEP、カーネル保護) が単に存在しない環境です。
esdiags.efi は Eurosoft の Pc-Check UEFI の一部として配布されている UEFI Shell であり、PC メーカー、サービス組織、IT チームがベアメタルシステムテストに使用するプリブートハードウェア診断製品です。
| プロパティ | 値 |
|---|---|
| ファイル | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| ベンダー | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| 署名 | Microsoft Corporation UEFI CA 2011 (Third Party) |
| 発見 | Eclypsium (Mickey Shkatov, Jesse Michael) - 2022年8月 |
| プレゼンテーション | DEF CON 30 - "One Bootloader to Load Them All" |
| 失効 | Microsoft KB5012170 経由で DBX に追加 (2022年8月) |
この脆弱性はバグではなく、設計上の欠陥 です。UEFI Shell は正規の診断ツールであり、Secure Boot 環境で実行されることは意図されていませんでした。しかし、Microsoft が信頼する証明書で署名し、商用製品の一部として配布することで、ベンダーは意図せず Secure Boot の署名済みバイパスを作成してしまいました。
核心的な問題: Secure Boot によって信頼されている署名済みバイナリが、その組み込みコマンドを通じて無制限のメモリ読み書き機能を提供します。この組み合わせが Secure Boot の信頼モデル全体を破壊します。
mm (memory modify) コマンドは、システムメモリへの直接的な読み書きアクセスを提供する標準的な UEFI Shell 組み込みコマンドです。UEFI Shell Specification (セクション 5.3) に記載されています。```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| パラメータ | 説明 |
|-----------|-------------|
| `Address` | 対象メモリアドレス |
| `Value` | 書き込む値（読み取り専用の場合は省略） |
| `-w` | 幅: 1、2、4、または 8 バイト |
| `-MEM` | システムメモリアクセス |
| `-MMIO` | メモリマップド I/O |
| `-IO` | I/O ポートアクセス |
| `-n` | 非対話型（次のアドレスのプロンプトを表示しない） |
---
<div id='gsecurity2'/>
### ***gSecurity2 とセキュリティアーキテクチャプロトコル***
UEFI における Secure Boot イメージ検証は、UEFI Platform Initialization (PI) 仕様で定義されている[セキュリティアーキテクチャプロトコル](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols)を通じて実施されます。
DXE コア (DxeMain) は [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) と呼ばれるグローバルポインタを保持しており、これは `EFI_SECURITY2_ARCH_PROTOCOL` 構造体を指します。このプロトコルには単一の関数ポインタ - `FileAuthenticationState` - が含まれており、UEFI イメージがロードされるたびに `LoadImage()` から呼び出されます:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
LoadImage() が呼び出されると、DXE コアは以下をチェックします:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
`gSecurity2 = NULL` を設定することで、`if` チェックが失敗し、`FileAuthenticationState` は決して呼び出されません。イメージ検証は完全にスキップされます - **Secure Boot は「有効」のままですが、もはや強制されません**。署名されていない UEFI アプリケーションはその後自由にロードできます。
この手法の深い技術的理解については、`gSecurity2` を自動的に特定してパッチを適用する専用の UEFI アプリケーションを含むコンパニオンプロジェクトを参照してください: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption)。
---
<div id='BYOVD'/>
### ***カーネル BYOVD との並行性***
UEFI BYOVUA とカーネル BYOVD の構造的な並行性は正確です:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA (Secure Boot Bypass) │
│ │
│ Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned │
│ (trusted by (Security2 Protocol) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ Kernel BYOVD (DSE Bypass) │
│ │
│ Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned │
│ (trusted by (CI.dll) kernel drivers │
│ DSE / CI) │
└──────────────────────────────────────────────────────────────┘
どちらの攻撃も同じ根本的な欠陥を悪用している。セキュリティ機構から信頼されている署名済みコンポーネントが、まさにその機構を無効化するために必要なプリミティブを提供してしまうのだ。
署名済みの esdiags.efi を EFI システムパーティション (ESP) に配置し、ブートオプションとして設定する。これは Secure Boot に信頼された証明書チェーンで署名されているため、ファームウェアは問題なく検証してロードする。```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── Bootx64.efi (Microsoft) ← Signed by Microsoft Windows UEFI Driver Publisher
└── Bootxsa.efi (Shell) ← Signed by Eurosoft (UK) Ltd
---
<div id='Phase2'/>
### ***Phase 2 - Security2 プロトコルハンドルの列挙***
UEFI Shell から、`EFI_SECURITY2_ARCH_PROTOCOL` (GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`) を公開しているハンドルを見つけ、そのプロトコルインターフェースのメモリアドレスを取得することが目標です。
> **Note:** `dh -p <GUID>` コマンドは、ほとんどの EDK2 Shell ビルドでは生の GUID を解決できません。登録されたプロトコル名のみを認識します。以下のアプローチはどの EDK2 Shell バージョンでも動作します。
**Step 1 - SecurityStubDxe ハンドルの検索**
すべてのハンドルを一覧表示し、`SecurityStubDxe` を探します。これは両方の Security Architectural Protocols をインストールする DXE ドライバーです:```
Shell> dh
出力で、SecurityStubDxe としてロードされたハンドルを特定します:```
10: Image(SecurityStubDxe)
**ステップ2 - 隣接するハンドルを検査する**