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

litebox-snp-novalidation-userptr

Classe: Primitive de escrita (R/W guest-to-SNP-kernel) Alcance: Local

LiteBox v0.1.0 (d8556e3) - Microsoft

O SNP LinuxKernel conecta UserConstPtr / UserMutPtr a NoValidation, que retorna o ponteiro inalterado. O comentário é TODO: implement pointer validation to ensure the pointers are in user space. O LVBS já faz verificação de intervalo USER_ADDR_MIN..USER_ADDR_END (0x10000 .. 0x7ffffffff000 em x86_64) e envolve as cópias em STAC/CLAC. O SNP não. O mmap do guest de um VA do kernel é rejeitado (TASK_ADDR_MAX), então stores em CPL3 não conseguem atingir o heap do kernel. O caminho de syscall roda em modo kernel e consegue. memcpy_fallible é rep movsb em modo supervisor.

Este resquício é R/W guest-to-SNP-kernel (VMPL2 LiteBox). Não é host VMPL0, não é hypervisor, e não é firmware SNP.

ID	ainda sem CVE
Classe	Primitive de escrita (R/W guest-to-SNP-kernel)
Alcance	Local (userspace de guest não confiável dentro de litebox_runner_snp)
CWE	CWE-823, CWE-119
CVSS	Alto: 8.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Produto	microsoft/litebox
Afetado	v0.1.0 (d8556e33676e47244bfefa139c1e9ff95bd67d53) plataforma de kernel SNP. TODO ainda em origin/main em 97001fd
Auth	guest já em execução dentro da VM SNP
Licença	GNU Affero GPL v3.0
Lab	apenas 127.0.0.1. Sem hardware SNP

O que um atacante pode fazer

Quem: userspace de guest não confiável dentro de litebox_runner_snp. A issue #505 (RFC aberta) é desta classe. O LVBS implementou. O SNP não.

Integridade (gadget comprovado em lab)

O lab é um gadget copy_from_slice em modo supervisor dos dois validadores mais uma cópia do pin litebox_platform_linux_kernel/src/lib.rs. Não é uma syscall de guest em hardware SNP.

Caminho	VA de destino	Resultado
SNP NoValidation (identidade)	0x1000 (abaixo de USER_ADDR_MIN) e 0xffff800000000000 (GVA_OFFSET)	aceita; memcpy escreve LITEBOX-SNP-NOVALIDATION-USERPTR-WITNESS no objeto rotulado como kernel
Verificação de intervalo LVBS	mesmos destinos de kernel	rejeita, errno=14 EFAULT, objeto de kernel vazio
Ambos	destino de usuário legal 0x400000	ambos copiam o witness para o objeto de usuário
Arquivo pin na imagem	n/a	comentário TODO mais UserConstPtr / UserMutPtr conectados a NoValidation (LvbsValidateAccess ausente)

Integridade (inferida do caminho de syscall do pin)

Método + sink	Privilégio
read / readv / pread / recv* / getcwd / uname / epoll_pwait com buf = VA de kernel -> UserMutPtr::copy_from_slice -> memcpy_fallible (rep movsb)	escreve até MAX_KERNEL_BUF_SIZE (512 KiB) por syscall, ou chunks de página de iovec, em qualquer VA mapeado do kernel SNP. O payload é escolhido pelo guest (pipe/arquivo que o guest escreveu)

Recon (inferido)

Método + sink	Privilégio
write / writev / send* com buf = VA de kernel -> read_at_offset	lê memória mapeada do kernel SNP para um fd do guest
VA de kernel não mapeado	EFAULT via tabela de exceções (mapeador de quais páginas de kernel existem)

Disponibilidade (inferida)

Método + sink	Privilégio
corromper heap do kernel SNP / tabelas de páginas / TLS do shim	travar ou desviar o kernel do guest SNP. Não afirmo um gadget RIP confiável

O que este resquício não concede

• Host VMPL0, hypervisor, firmware SNP
• LVBS VTL1 (LvbsValidateAccess + STAC/CLAC)
• sysretq para um RIP de kernel (sanitize_for_user_return recusa RIP/RSP não-usuário)
• mmap / mprotect do guest de VA de kernel (TASK_ADDR_MAX)
• NoValidation de userland Linux/Windows (mesmo processo; a fronteira de host ali é seccomp, esse é um resquício irmão)
• Não é uma quebra da confidencialidade do C-bit do SEV-SNP por si só. É uma cópia de confused-deputy dentro do kernel SNP do LiteBox

Como eu encontrei

litebox_platform_linux_kernel/src/lib.rs linhas 59-67 na v0.1.0. O TODO ainda está na main. O LVBS já tem LvbsValidateAccess com USER_ADDR_MIN = 0x10000 e USER_ADDR_MAX = 0x7ffffffff000. Eu não tinha hardware SNP. O lab copia o arquivo pin, implementa identidade vs verificação de intervalo, e escreve o witness através de NoValidation em VAs de destino que a verificação LVBS rejeita.

Lab

cd lab
./run.sh

Loopback 127.0.0.1:19130. Projeto Compose litebox-snp-novalidation-userptr. Witness LITEBOX-SNP-NOVALIDATION-USERPTR-WITNESS. Última linha:

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

Correção

Conecte o UserPtr do SNP à mesma verificação de intervalo de userspace que o LVBS já tem (USER_ADDR_MIN..USER_ADDR_END), e mantenha as cópias atrás da tabela de exceções. Não deixe NoValidation em uma plataforma de kernel.

O intake do fornecedor é o MSRC (https://msrc.microsoft.com/create-report). Não abra uma issue pública no GitHub em microsoft/litebox.

Contato

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