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

litebox-snp-novalidation-userptr

Classe : Primitive d'écriture (R/W guest-vers-noyau-SNP) Portée : Locale

LiteBox v0.1.0 (d8556e3) - Microsoft

Le LinuxKernel SNP câble UserConstPtr / UserMutPtr sur NoValidation, qui renvoie le pointeur inchangé. Le commentaire est TODO: implement pointer validation to ensure the pointers are in user space. LVBS effectue déjà une vérification de plage USER_ADDR_MIN..USER_ADDR_END (0x10000 .. 0x7ffffffff000 sur x86_64) et encapsule les copies dans STAC/CLAC. SNP ne le fait pas. Le mmap invité d'une VA noyau est rejeté (TASK_ADDR_MAX), donc les stores CPL3 ne peuvent pas atteindre le tas noyau. Le chemin d'appel système s'exécute en mode noyau et le peut. memcpy_fallible est rep movsb en mode superviseur.

Ce reliquat est un R/W guest-vers-noyau-SNP (VMPL2 LiteBox). Ce n'est pas l'hôte VMPL0, ni l'hyperviseur, ni le firmware SNP.

ID	pas encore de CVE
Classe	Primitive d'écriture (R/W guest-vers-noyau-SNP)
Portée	Locale (espace utilisateur invité non fiable à l'intérieur de litebox_runner_snp)
CWE	CWE-823, CWE-119
CVSS	Élevé : 8.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Produit	microsoft/litebox
Affecté	v0.1.0 (d8556e33676e47244bfefa139c1e9ff95bd67d53) plateforme noyau SNP. Le TODO est toujours sur origin/main à partir de 97001fd
Auth	l'invité s'exécute déjà à l'intérieur de la VM SNP
Licence	GNU Affero GPL v3.0
Lab	127.0.0.1 uniquement. Pas de matériel SNP

Ce qu'un attaquant peut faire

Qui : espace utilisateur invité non fiable à l'intérieur de litebox_runner_snp. L'issue #505 (RFC ouverte) concerne cette classe. LVBS l'a implémentée. SNP ne l'a pas fait.

Intégrité (gadget prouvé en lab)

Le lab est un gadget copy_from_slice en mode superviseur des deux validateurs plus une copie du fichier pin litebox_platform_linux_kernel/src/lib.rs. Ce n'est pas un appel système invité sur du matériel SNP.

Chemin	VA de destination	Résultat
SNP NoValidation (identité)	0x1000 (sous USER_ADDR_MIN) et 0xffff800000000000 (GVA_OFFSET)	accepte ; memcpy écrit LITEBOX-SNP-NOVALIDATION-USERPTR-WITNESS dans l'objet étiqueté noyau
Vérification de plage LVBS	mêmes destinations noyau	rejette, errno=14 EFAULT, objet noyau vide
Les deux	destination utilisateur légale 0x400000	les deux copient le témoin dans l'objet utilisateur
Fichier pin dans l'image	n/a	commentaire TODO plus UserConstPtr / UserMutPtr câblés sur NoValidation (LvbsValidateAccess absent)

Intégrité (déduite du chemin d'appel système du pin)

Méthode + sink	Privilège
read / readv / pread / recv* / getcwd / uname / epoll_pwait avec buf = VA noyau -> UserMutPtr::copy_from_slice -> memcpy_fallible (rep movsb)	écrit jusqu'à MAX_KERNEL_BUF_SIZE (512 KiB) par appel système, ou des morceaux de page iovec, dans n'importe quelle VA noyau SNP mappée. La charge utile est choisie par l'invité (pipe/fichier que l'invité a écrit)

Reconnaissance (déduite)

Méthode + sink	Privilège
write / writev / send* avec buf = VA noyau -> read_at_offset	lit la mémoire noyau SNP mappée dans un fd invité
VA noyau non mappée	EFAULT via la table d'exceptions (mappeur des pages noyau qui existent)

Disponibilité (déduite)

Méthode + sink	Privilège
corrompre le tas noyau SNP / les tables de pages / le TLS du shim	planter ou détourner le noyau invité SNP. Je ne revendique pas de gadget RIP fiable

Ce que ce reliquat n'accorde pas

• Hôte VMPL0, hyperviseur, firmware SNP
• LVBS VTL1 (LvbsValidateAccess + STAC/CLAC)
• sysretq vers un RIP noyau (sanitize_for_user_return refuse les RIP/RSP non-utilisateur)
• mmap / mprotect invité d'une VA noyau (TASK_ADDR_MAX)
• NoValidation en espace utilisateur Linux/Windows (même processus ; la frontière hôte là-bas est seccomp, c'est un reliquat frère)
• Pas une rupture de la confidentialité du C-bit SEV-SNP en soi. C'est une copie confused-deputy à l'intérieur du noyau SNP LiteBox

Comment je l'ai trouvé

litebox_platform_linux_kernel/src/lib.rs lignes 59-67 sur v0.1.0. Le TODO est toujours sur main. LVBS possède déjà LvbsValidateAccess avec USER_ADDR_MIN = 0x10000 et USER_ADDR_MAX = 0x7ffffffff000. Je n'avais pas de matériel SNP. Le lab copie le fichier pin, implémente l'identité vs la vérification de plage, et écrit le témoin via NoValidation dans des VA de destination que la vérification LVBS rejette.

Lab

cd lab
./run.sh

Loopback 127.0.0.1:19130. Projet Compose litebox-snp-novalidation-userptr. Témoin LITEBOX-SNP-NOVALIDATION-USERPTR-WITNESS. Dernière ligne :

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

Correctif

Câbler le UserPtr SNP sur la même vérification de plage d'espace utilisateur que LVBS possède déjà (USER_ADDR_MIN..USER_ADDR_END), et garder les copies derrière la table d'exceptions. Ne pas laisser NoValidation sur une plateforme noyau.

L'admission fournisseur est MSRC (https://msrc.microsoft.com/create-report). Ne pas ouvrir d'issue GitHub publique sur microsoft/litebox.

Contact

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