<p><meta/> [Author: Senior CSIRT Engineer] [Knowledge_Cutoff: 2024-05] [Focus: AI Infrastructure Security, RCE Mitigation, Supply Chain Security] [Priority: High – Critical Vulnerability Patching] </p> <p>本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">GitLab AI Gateway & vLLMにおけるRCE/認証バイパス：AIインフラの信頼境界再設計</h1> <h2 class="wp-block-heading">【脅威の概要と背景】</h2> <p>AI Gatewayの認可バイパス（CVE-2024-4543等）とvLLMのJinja2テンプレート悪用によるRCE（CVE-2024-34359）が特定されました。これらはAI連携を急ぐ企業インフラにおいて、未認証の攻撃者がモデル実行権限を奪取し、内部データへアクセスする重大なリスクをもたらします。</p> <h2 class="wp-block-heading">【攻撃シナリオの可視化】</h2> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> graph TD Attacker["攻撃者"] -->|1. 不正なAuthorizationヘッダー| AI_Gateway["GitLab AI Gateway"] AI_Gateway -->|2. 認可バイパス| Internal_LLM["内部LLMエンジン"] Attacker -->|3. 悪意あるchat_templateの注入| vLLM["vLLM Server"] vLLM -->|4. Jinja2テンプレート展開| RCE["OSコマンド実行"] RCE -->|5. 資格情報奪取| Cloud_Env["クラウド基盤"] </pre></div> <h2 class="wp-block-heading">【安全な実装と設定】</h2> <h3 class="wp-block-heading">1. vLLMにおけるテンプレート実行の制限</h3> <p>vLLMの脆弱性（CVE-2024-34359）は、モデルの<code>tokenizer_config.json</code>に含まれる<code>chat_template</code>（Jinja2）が適切にサンドボックス化されていないことに起因します。</p> <p><strong>誤用例（脆弱な設定）:</strong> 信頼できないソース（Hugging Faceの公開リポジトリ等）からモデルを直接読み込み、デフォルト設定でサービングする。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 脆弱な起動例 python -m vllm.entrypoints.openai.api_server --model /path/to/untrusted-model </pre> </div> <p><strong>安全な代替案（要塞化）:</strong> カスタムテンプレートを明示的に指定し、モデル側の設定を上書き、または読み込みを拒否します。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># 安全な起動例：信頼できるテンプレートを強制適用 python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --chat-template ./safe_templates/llama3_template.jinja \ --disable-log-requests </pre> </div> <h3 class="wp-block-heading">2. AI Gatewayの認証保護（GitLab）</h3> <p>GitLab AI Gatewayのバイパスを防ぐには、インスタンス側のパッチ適用に加え、ネットワーク層での制限が必須です。</p> <p><strong>推奨される構成（Terraform/IAMポリシー例）:</strong> AI Gatewayへのアクセスを特定のGitLab RailsインスタンスのIPおよびサービスアカウントに限定します。</p> <div class="codehilite"> <pre data-enlighter-language="generic"># セキュリティグループの制限例 resource "aws_security_group_rule" "allow_gitlab_rails" { type = "ingress" from_port = 50052 to_port = 50052 protocol = "tcp" source_security_group_id = aws_security_group.gitlab_rails.id description = "Only allow traffic from GitLab Rails to AI Gateway" } </pre> </div> <h2 class="wp-block-heading">【検出と緩和策】</h2> <h3 class="wp-block-heading">1. 検出ポイント（SIEM/EDR）</h3> <ul class="wp-block-list"> <li><p><strong>vLLMプロセスからの不審な子プロセス生成:</strong> <code>vllm</code> プロセスを親として <code>whoami</code>, <code>curl</code>, <code>sh</code> 等が起動していないか監視。</p></li> <li><p><strong>Jinja2 特有のペイロード:</strong> ログ内の <code>{{</code>, <code>config.__class__</code>, <code>mro</code> 等の文字列を検知。</p></li> <li><p><strong>AI Gateway ログ:</strong> HTTP 401/403 エラーの急増と、その直後の成功レスポンス（バイパス試行の兆候）。</p></li> </ul> <h3 class="wp-block-heading">2. 応急的な緩和策（Workaround）</h3> <ul class="wp-block-list"> <li><p><strong>外部通信の遮断:</strong> vLLMインスタンスからの外部（インターネット）へのアウトバウンド通信をセキュリティグループ/FWで遮断。</p></li> <li><p><strong>読み取り専用ファイルシステム:</strong> モデル実行環境のコンテナを <code>--read-only</code> で実行し、攻撃者によるバックドア設置を困難にする。</p></li> </ul> <h2 class="wp-block-heading">【実務上の落とし穴】</h2> <ul class="wp-block-list"> <li><p><strong>可用性への影響:</strong> テンプレート制限を厳しくしすぎると、一部の高度なプロンプトエンジニアリング（マルチモーダル処理等）が動作しなくなる「可用性のトレードオフ」が発生します。</p></li> <li><p><strong>シャドーAIの存在:</strong> 開発者が公式のAI Gatewayを通さず、ローカルや勝手に立てたGPUサーバーでvLLMを動かしている場合、組織の統制外でRCEリスクが放置されるリスクがあります。</p></li> </ul> <h2 class="wp-block-heading">【まとめ】</h2> <p>組織のCSIRTおよびインフラ担当者が今すぐ実施すべき事項：</p> <ol class="wp-block-list"> <li><p><strong>即時アップデート:</strong> GitLab (v17.0.1+, v16.11.2+) および vLLM (v0.4.2+) への更新。</p></li> <li><p><strong>テンプレートの検証:</strong> 使用中の全LLMモデルの <code>tokenizer_config.json</code> 内に、不審なJinja2コードが含まれていないか静的スキャンを実施。</p></li> <li><p><strong>最小権限の徹底:</strong> AI Gatewayをインターネットに直接さらさず、内部ネットワークかつ認証必須の構成に強制移行。</p></li> </ol> <hr/> <p><strong>参考文献:</strong></p> <ul class="wp-block-list"> <li><p><a href="https://about.gitlab.com/releases/categories/releases/">GitLab Security Release: 17.0.1, 16.11.2, 16.10.5</a></p></li> <li><p><a href="https://nvd.nist.gov/vuln/detail/CVE-2024-34359">NVD – CVE-2024-34359 (vLLM RCE)</a></p></li> <li><p><a href="https://www.jpcert.or.jp/">JPCERT/CC: AIソフトウェアにおける脆弱性管理の重要性</a></p></li> </ul>

graph TD
    Attacker["攻撃者"] -->|1. 不正なAuthorizationヘッダー| AI_Gateway["GitLab AI Gateway"]
    AI_Gateway -->|2. 認可バイパス| Internal_LLM["内部LLMエンジン"]
    Attacker -->|3. 悪意あるchat_templateの注入| vLLM["vLLM Server"]
    vLLM -->|4. Jinja2テンプレート展開| RCE["OSコマンド実行"]
    RCE -->|5. 資格情報奪取| Cloud_Env["クラウド基盤"]

# 脆弱な起動例

python -m vllm.entrypoints.openai.api_server --model /path/to/untrusted-model

# 安全な起動例：信頼できるテンプレートを強制適用

python -m vllm.entrypoints.openai.api_server \
    --model /path/to/model \
    --chat-template ./safe_templates/llama3_template.jinja \
    --disable-log-requests

# セキュリティグループの制限例

resource "aws_security_group_rule" "allow_gitlab_rails" {
  type              = "ingress"
  from_port         = 50052
  to_port           = 50052
  protocol          = "tcp"
  source_security_group_id = aws_security_group.gitlab_rails.id
  description       = "Only allow traffic from GitLab Rails to AI Gateway"
}