yoshino-s/cve-2025-62506CVE-2025-62506の検証スクリプト。MinIOサービスアカウントにおける権限昇格の脆弱性で、制限されたアカウントがインラインポリシーをバイパスして無制限のアカウントを作成できるかどうかをテストします。
このリポジトリには、MinIO サービスアカウントおよび STS（Security Token Service）アカウントにおける権限昇格の脆弱性である CVE-2025-62506 の検証スクリプトが含まれています。
CVE-2025-62506 は、制限付きサービスアカウントおよび STS アカウントが、同じユーザーに対して新しいサービスアカウントを作成する際に、自身のアカウント操作を実行するときにインラインポリシーの制限を回避できる権限昇格の脆弱性です。
この脆弱性は、cmd/iam.go の IAM ポリシー検証ロジックに存在します。制限付きアカウントが自身のアカウントに対して操作（サービスアカウントの作成など）を実行する際のセッションポリシーを検証するとき、コードは DenyOnly 引数に誤って依存していました。
DenyOnly フラグは、アクションが明示的に拒否されているかどうかのみをチェックすることで、アカウントが自身のアカウントに関連するアクションを実行できるようにするために使用されます。しかし、セッションポリシー（サブポリシー）が存在する場合、システムはアクションが拒否されていないことだけでなく、セッションポリシーによって実際に許可されていることを検証する必要があります。
8.1（高） - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
RELEASE.2025-10-15T17-29-55Z より前のすべてのバージョン
RELEASE.2025-10-15T17-29-55Z
verify_cve_2025_62506.py スクリプトは、MinIO インストールが CVE-2025-62506 に対して脆弱かどうかをテストします。
docker-compose.yml で起動可能）miniodocker-compose up -d
pip install minio
検証スクリプトは以下の手順を実行します:
bucket1、bucket2、bucket3bucket1 と bucket2 へのアクセスのみを許可する IAM ポリシーを作成s3:*（すべての S3 操作）bucket1/*、bucket2/*bucket3 を含む）restrictedrestricted123bucket1 と bucket2 のみ表示されるbucket3）へのアクセスを試行docker-compose up -d
python verify_cve_2025_62506.py
🚀 CVE-2025-62506 脆弱性検証スクリプト
============================================================
📋 スクリプトの説明:
このスクリプトは MinIO サービスアカウントの権限昇格の脆弱性（CVE-2025-62506）をテストします
この脆弱性により、制限付きサービスアカウントが新しいアカウント作成時にインラインポリシーをバイパスできます
============================================================
📦 ステップ 1: テストバケットの作成
3 つのテストバケットを作成: bucket1、bucket2、bucket3
アカウントのアクセス権限制限をテストするために使用
----------------------------------------
✅ バケットを作成: bucket1
✅ バケットを作成: bucket2
✅ バケットを作成: bucket3
🔒 ステップ 2: 制限付きポリシーの作成
bucket1 と bucket2 へのアクセスのみを許可するポリシーを作成
このポリシーは制限付きサービスアカウントに適用されます
----------------------------------------
✅ ポリシーを作成: restricted-policy
📋 ポリシーの権限:
- 許可されるアクション: s3:*（すべての S3 操作）
- 許可されるリソース: bucket1/*、bucket2/*
- 拒否されるリソース: その他すべてのバケット
👤 ステップ 3: 制限付きサービスアカウントの作成
上記の制限付きポリシーを持つサービスアカウントを作成
このアカウントは bucket1 と bucket2 にのみアクセスできます
----------------------------------------
✅ サービスアカウントを作成: restricted
📋 アカウントの権限:
- アクセスキー: restricted
- ポリシー: インライン制限付きポリシー（bucket1 と bucket2 のみ）
- 期待される動作: 指定されたバケットのみにアクセス可能
🧪 ステップ 4: 制限付きアカウントのアクセステスト
制限付きアカウントを使用してバケットを一覧表示し、権限が適切に制限されていることを検証
期待される結果: bucket1 と bucket2 のみ表示される
----------------------------------------
✅ 制限付きアカウントは許可されたバケットに正しく制限されています
アクセス可能なバケット: ['bucket1', 'bucket2']
⚡ ステップ 5: 権限昇格の試行（脆弱性テスト）
制限付きアカウントを使用して新しいサービスアカウントの作成を試行
ポリシーを指定しない新しいアカウントは親の制限を継承するはず
脆弱性: 制限付きアカウントがポリシーをバイパスして無制限の新しいアカウントを作成する可能性
----------------------------------------
✅ サービスアカウントを作成: newroot
📋 新しいサービスアカウントを使用して不正な bucket3 へのアクセスを試行
⬆️ 権限を検証するために bucket3 へのオブジェクトのアップロードを試行
⬇️ 権限を検証するためにオブジェクトの一覧表示を試行
オブジェクトを検出: test-object
❌ 脆弱性あり: 制限付きアカウントが新しいサービスアカウントの作成に成功
新しいアカウントの権限: 無制限（親の完全な権限を継承）
これは CVE-2025-62506 の脆弱性が存在することを示しています！
🧹 テストリソースをクリーンアップ中...
----------------------------------------
✅ サービスアカウントを削除: restricted
✅ サービスアカウントを削除: newroot
✅ ポリシーを削除: restricted-policy
✅ バケットを削除: bucket1
✅ バケットを削除: bucket2
✅ バケットを削除: bucket3
============================================================
📊 検証結果
============================================================
❌ 結果: 脆弱性あり - CVE-2025-62506 が存在します
💡 推奨事項: パッチ適用済みバージョン RELEASE.2025-10-15T17-29-55Z 以上に直ちにアップグレードしてください
🔗 参考: https://github.com/minio/minio/security/advisories/GHSA-jjjj-jwhf-8rgr
============================================================
🚀 CVE-2025-62506 脆弱性検証スクリプト
============================================================
📋 スクリプトの説明:
このスクリプトは MinIO サービスアカウントの権限昇格の脆弱性（CVE-2025-62506）をテストします
この脆弱性により、制限付きサービスアカウントが新しいアカウント作成時にインラインポリシーをバイパスできます
============================================================
📦 ステップ 1: テストバケットの作成
3 つのテストバケットを作成: bucket1、bucket2、bucket3
アカウントのアクセス権限制限をテストするために使用
----------------------------------------
✅ バケットを作成: bucket1
✅ バケットを作成: bucket2
✅ バケットを作成: bucket3
🔒 ステップ 2: 制限付きポリシーの作成
bucket1 と bucket2 へのアクセスのみを許可するポリシーを作成
このポリシーは制限付きサービスアカウントに適用されます
----------------------------------------
✅ ポリシーを作成: restricted-policy
📋 ポリシーの権限:
- 許可されるアクション: s3:*（すべての S3 操作）
- 許可されるリソース: bucket1/*、bucket2/*
- 拒否されるリソース: その他すべてのバケット
👤 ステップ 3: 制限付きサービスアカウントの作成
上記の制限付きポリシーを持つサービスアカウントを作成
このアカウントは bucket1 と bucket2 にのみアクセスできます
----------------------------------------
✅ サービスアカウントを作成: restricted
📋 アカウントの権限:
- アクセスキー: restricted
- ポリシー: インライン制限付きポリシー（bucket1 と bucket2 のみ）
- 期待される動作: 指定されたバケットのみにアクセス可能
🧪 ステップ 4: 制限付きアカウントのアクセステスト
制限付きアカウントを使用してバケットを一覧表示し、権限が適切に制限されていることを検証
期待される結果: bucket1 と bucket2 のみ表示される
----------------------------------------
✅ 制限付きアカウントは許可されたバケットに正しく制限されています
アクセス可能なバケット: ['bucket1', 'bucket2']
⚡ ステップ 5: 権限昇格の試行（脆弱性テスト）
制限付きアカウントを使用して新しいサービスアカウントの作成を試行
ポリシーを指定しない新しいアカウントは親の制限を継承するはず
脆弱性: 制限付きアカウントがポリシーをバイパスして無制限の新しいアカウントを作成する可能性
----------------------------------------
✅ 安全: 制限付きアカウントは新しいサービスアカウントの作成に失敗
エラー: 権限が正しく拒否されました
詳細: Access Denied.
🧹 テストリソースをクリーンアップ中...
----------------------------------------
✅ サービスアカウントを削除: restricted
✅ ポリシーを削除: restricted-policy
✅ バケットを削除: bucket1
✅ バケットを削除: bucket2
✅ バケットを削除: bucket3
============================================================
📊 検証結果
============================================================
✅ 結果: 安全 - CVE-2025-62506 はパッチ適用済みです
🎉 お使いの MinIO バージョンにはこの脆弱性のパッチが適用されています
============================================================
この検証スクリプトは、セキュリティテスト目的で現状のまま提供されます。