Kata Containers安全漏洞CVE-2025-58354

摘要

栋科技漏洞库关注到 Kata Containers 受影响版本中存在一个安全漏洞，该漏洞现在已经被追踪为CVE-2025-58354，CVSS 3.X评分7.3。

Kata Containers是Novel实现的轻量虚拟机，可无缝地与容器生态系统进行集成，将虚拟化安全隔离优势和容器的快速启动特点结合起来。

Kata Containers 是结合了容器技术和虚拟机技术的轻量级运行时，旨在提供容器的速度和虚拟机安全性，提升安全性并保持容器高效性。

一、基本情况

Kata Containers 是一个专注于实现轻量级虚拟机（VMs）的开源项目，专注于实现像容器一样运行的轻量级虚拟机（VMs）的标准实现。

Kata Containers安全漏洞CVE-2025-58354

Kata Containers 旨在提供与传统容器相同的用户体验，同时增强了安全性和隔离性。Kata Containers 将每个容器运行在独立的虚拟机中。

栋科技漏洞库关注到 Kata Containers 受影响版本中存在一个安全漏洞，该漏洞现在已经被追踪为CVE-2025-58354，CVSS 3.X评分7.3。

二、漏洞分析

CVE-2025-58354漏洞是在Kata Containers的3.20.0版本及之前的版本中存在的一个安全漏洞，该漏洞允许恶意主机可以绕过initData验证。

在支持 TDX（Intel Trust Domain Extensions）系统上，运行机密容器的场景中，恶意主机可选择性地使 I/O 操作失败，跳过 initdata 验证。

这导致攻击者可以在不被检测的情况下，成功证明受托人伪装，运行任意工作负载，并向 Trustee 成功验证身份，冒充任何良性工作负载。

具体来说，确保TEE的VM完整性的规范方法是使用代理策略向VM提供initdata，该策略限制了运行时可以在代理上执行的操作。

在应用代理策略之前，Kata代理启动证明代理并等待，直到它绑定到策略。只有在绑定initdata之后，代理才会继续接受来自主机的请求。

漏洞仅适用于使用rootfs和dm-verity的CoCo变体：若客户组件二进制文件位于initrd中则主机无法拦截IO（这发生在加密的客户内存中）。

裸金属TDX就是这种情况，所有TEE上的CAA也可能是这种情况（未检查）。

易受攻击的系统允许攻击者（具有主机权限）配置他们选择的策略（例如allow-all.rego），

同时能够为他们选择的initdata哈希生成证明语句（通过MRCONFIGID或TPM PCR）。

1、只有当证明代理是rootfs的一部分时，它才会启动，但策略将无条件设置：

kata-containers/src/agent/src/main.rs

Lines 410 to 431 in c980b6e

 if !attestation_binaries_available(logger, &gc_procs) { 
     warn!( 
         logger, 
         "attestation binaries requested for launch not available" 
     ); 
 } else { 
     init_attestation_components(logger, config, &initdata_return_value).await?; 
 } 

 // if policy is given via initdata, use it 
 #[cfg(feature = "agent-policy")] 
 if let Some(initdata_return_value) = initdata_return_value { 
     if let Some(policy) = &initdata_return_value._policy { 
         info!(logger, "using policy from initdata"); 
         AGENT_POLICY 
             .lock() 
             .await 
             .set_policy(policy) 
             .await 
             .context("Failed to set policy from initdata")?; 
     } 
 }

2、通过以下检查确定AA是否是rootfs的一部分：

kata-containers/src/agent/src/main.rs

Lines 460 to 474 in c980b6e

 fn attestation_binaries_available(logger: &Logger, procs: &GuestComponentsProcs) -> bool { 
     let binaries = match procs { 
         GuestComponentsProcs::AttestationAgent => vec![AA_PATH], 
         GuestComponentsProcs::ConfidentialDataHub => vec![AA_PATH, CDH_PATH], 
         GuestComponentsProcs::ApiServerRest => vec![AA_PATH, CDH_PATH, API_SERVER_PATH], 
         _ => vec![], 
     }; 
     for binary in binaries.iter() { 
         if !Path::new(binary).exists() { 
             warn!(logger, "{} not found", binary); 
             return false; 
         } 
     } 
     true 
 }

此函数包含一个错误：

即使路径确实存在，Path::exists也可能返回false，例如在IO错误时(https://doc.rust-lang.org/src/std/path.rs.html#3135-3136).

主机有两种方法可以强制IO错误：

如果主机篡改了包含AA二进制文件的rootfs部分，则验证设置将检测到这一点，并导致EIO返回。

如果主机刚刚失败了对各个扇区的读取调用，这也可能在EIO中表现出来。

3、由于未设置panic_on_corruption或panic_on_error，VM应继续运行，跳过initdata验证。

kata-containers/tools/packaging/static-build/initramfs/init.sh

Line 51 in c980b6e

veritysetup open "${root_device}" root "${hash_device}" "${rootfs_hash}"

三、影响范围

kata-containers <= 3.21.0

四、修复建议

kata-containers > 3.21.0

五、修复建议