abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  litebox-snp-novalidation-userptr

litebox-snp-novalidation-userptr

类别： 写原语（guest 到 SNP 内核的读/写） 可达性： 本地

LiteBox v0.1.0 (d8556e3) - Microsoft

SNP LinuxKernel 将 UserConstPtr / UserMutPtr 连接到 NoValidation，后者原样返回指针。注释为 TODO: implement pointer validation to ensure the pointers are in user space. LVBS 已经对 USER_ADDR_MIN..USER_ADDR_END（x86_64 上为 0x10000 .. 0x7ffffffff000）进行范围检查，并将拷贝包裹在 STAC/CLAC 中。SNP 没有。Guest 对内核 VA 的 mmap 会被拒绝（TASK_ADDR_MAX），因此 CPL3 存储无法命中内核堆。系统调用路径在内核模式下运行，可以命中。memcpy_fallible 在监管模式下是 rep movsb。

这个遗留问题是 guest 到 SNP 内核（VMPL2 LiteBox）的读/写。它不是宿主 VMPL0，不是 hypervisor，也不是 SNP 固件。

ID	尚无 CVE
类别	写原语（guest 到 SNP 内核的读/写）
可达性	本地（litebox_runner_snp 内不受信任的 guest 用户空间）
CWE	CWE-823, CWE-119
CVSS	高：8.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
产品	microsoft/litebox
受影响	v0.1.0 (d8556e33676e47244bfefa139c1e9ff95bd67d53) SNP 内核平台。截至 97001fd，TODO 仍在 origin/main 上
认证	guest 已在 SNP VM 内运行
许可证	GNU Affero GPL v3.0
实验环境	仅 127.0.0.1。无 SNP 硬件

攻击者能做什么

谁：litebox_runner_snp 内不受信任的 guest 用户空间。Issue #505（开放的 RFC）就是这一类。LVBS 已实现。SNP 没有。

完整性（实验环境验证的 gadget）

实验环境是一个监管模式下的 copy_from_slice gadget，包含两个验证器以及 pin 文件 litebox_platform_linux_kernel/src/lib.rs 的副本。它不是 SNP 硬件上的 guest 系统调用。

路径	目标 VA	结果
SNP NoValidation（恒等）	0x1000（低于 USER_ADDR_MIN）和 0xffff800000000000（GVA_OFFSET）	接受；memcpy 将 LITEBOX-SNP-NOVALIDATION-USERPTR-WITNESS 写入内核标记对象
LVBS 范围检查	相同的内核目标	拒绝，errno=14 EFAULT，内核对象为空
两者	合法用户目标 0x400000	两者都将 witness 拷贝到用户对象
镜像中的 pin 文件	不适用	TODO 注释以及连接到 NoValidation 的 UserConstPtr / UserMutPtr（LvbsValidateAccess 缺失）

完整性（从 pin 系统调用路径推断）

方法 + 汇聚点	权限
read / readv / pread / recv* / getcwd / uname / epoll_pwait，buf = 内核 VA -> UserMutPtr::copy_from_slice -> memcpy_fallible（rep movsb）	每次系统调用向任意已映射的 SNP 内核 VA 写入最多 MAX_KERNEL_BUF_SIZE（512 KiB），或 iovec 页块。载荷由 guest 选择（guest 写入的管道/文件）

侦察（推断）

方法 + 汇聚点	权限
write / writev / send*，buf = 内核 VA -> read_at_offset	将已映射的 SNP 内核内存读入 guest fd
未映射的内核 VA	通过异常表返回 EFAULT（哪些内核页存在的映射器）

可用性（推断）

方法 + 汇聚点	权限
破坏 SNP 内核堆 / 页表 / shim TLS	使 SNP guest 内核崩溃或改道。我不声称有可靠的 RIP gadget

这个遗留问题不授予什么

• 宿主 VMPL0、hypervisor、SNP 固件
• LVBS VTL1（LvbsValidateAccess + STAC/CLAC）
• sysretq 到内核 RIP（sanitize_for_user_return 拒绝非用户 RIP/RSP）
• Guest 对内核 VA 的 mmap / mprotect（TASK_ADDR_MAX）
• Linux/Windows 用户态 NoValidation（同一进程；那里的宿主边界是 seccomp，那是同类遗留问题）
• 本身不是对 SEV-SNP C-bit 机密性的破坏。它是 LiteBox SNP 内核内部的混淆代理拷贝

我是如何发现的

litebox_platform_linux_kernel/src/lib.rs 第 59-67 行，v0.1.0。TODO 仍在 main 上。LVBS 已经有 LvbsValidateAccess，带有 USER_ADDR_MIN = 0x10000 和 USER_ADDR_MAX = 0x7ffffffff000。我没有 SNP 硬件。实验环境复制 pin 文件，实现恒等与范围检查，并通过 NoValidation 将 witness 写入 LVBS 检查拒绝的目标 VA。

实验环境

cd lab
./run.sh

回环 127.0.0.1:19130。Compose 项目 litebox-snp-novalidation-userptr。Witness LITEBOX-SNP-NOVALIDATION-USERPTR-WITNESS。最后一行：

SUCCESS litebox-snp-novalidation-userptr novalidation-kernel-write-ok lvbs-range-reject pin-TODO-present user-range-copy-ok LITEBOX-SNP-NOVALIDATION-USERPTR-WITNESS

修复

将 SNP UserPtr 连接到 LVBS 已有的相同用户空间范围检查（USER_ADDR_MIN..USER_ADDR_END），并将拷贝保持在异常表之后。不要在内核平台上留下 NoValidation。

供应商接收渠道是 MSRC（https://msrc.microsoft.com/create-report）。不要在 microsoft/litebox 上开公开的 GitHub issue。

联系方式

Abraxas Labs - abraxaslabs.tech - github.com/abraxas - @abraxas_null - [email protected]