abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  litebox-seccomp-open-rdonly

litebox-seccomp-open-rdonly

Classe : Lecture de fichier (frontière FS du bac à sable) Portée : Locale

LiteBox v0.1.0 (d8556e3) - Microsoft

Le runner Linux-userland documenté (litebox-runner-linux-userland) installe un filtre seccomp en deny-by-default, puis charge un ELF invité dans le même processus. SYS_open figure sur la liste d'autorisation lorsque l'argument 1 (flags) est un dword égal à OFlags::RDONLY (0). Il n'y a aucun prédicat de chemin. Un invité qui émet un véritable syscall avec les flags 0 ouvre le VFS hôte avec l'UID du runner, puis read / mmap ces octets. Le réécrivain ELF n'est pas une frontière de sécurité sur ce pin. --rewrite-syscalls est -Z et désactivé par défaut.

Ce reliquat est une lecture du FS hôte. Ce n'est pas une écriture hôte, ni exec, ni ptrace, ni LPE, ni RCE.

ID	pas encore de CVE
Classe	Lecture de fichier (frontière FS du bac à sable)
Portée	Locale (binaire invité non fiable dans le processus du runner)
CWE	CWE-284, CWE-862
CVSS	Élevé : 7.1 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Produit	microsoft/litebox
Affecté	v0.1.0 (d8556e33676e47244bfefa139c1e9ff95bd67d53) plateforme Linux userland + runner
Auth	invité déjà en cours d'exécution dans le bac à sable
Licence	GNU Affero GPL v3.0
Lab	127.0.0.1 uniquement, linux/amd64

Ce qu'un attaquant peut faire

Qui : un binaire invité non fiable dans litebox-runner-linux-userland. Le fournisseur (CvvT sur GitHub #1006) et la documentation du crate du réécrivain indiquent que les trampolines ELF ne sont pas une frontière de sécurité. La sécurité du userland Linux, c'est ce filtre. enable_seccomp_filter est en deny-by-default (Errno(EINVAL) en release) avec TSYNC et PR_SET_NO_NEW_PRIVS. La faille est SYS_open avec flags Eq 0 sans vérification de chemin. Le commentaire dans page_mgmt.rs indique que le mapping CoW réouvre le fichier programme hôte après l'activation du filtre, au lieu de conserver un FD pré-ouvert.

Reconnaissance (prouvée en lab)

Méthode + sink	Privilège
véritable SYS_open("/oracle/secret", 0) puis SYS_read	Octets du fichier hôte que l'UID du runner peut lire. Lab : fd 3, 35 octets, témoin LITEBOX-SECCOMP-OPEN-RDONLY-WITNESS. Le chemin est le VFS hôte de l'initramfs, pas l'overlay invité.

Reconnaissance (déduite du même filtre ; pas l'oracle du lab)

Méthode + sink	Privilège
SYS_open("/etc/passwd", 0) puis read / mmap	fichiers hôtes lisibles par tous avec l'UID du runner
SYS_open de chemins appartenant au runner (clés ssh, .env, kubeconfig, identifiants cloud, tar --initial-files)	ces octets si l'UID peut les ouvrir
SYS_open("/etc/shadow", 0)	hachages shadow uniquement si le runner est root
SYS_open("/proc/self/maps", 0)	mappings du runner, y compris .text hôte / libc (même processus)
SYS_open("/proc/self/mem", 0) puis mmap du FD	espace d'adressage du runner que l'UID peut lire via procfs. pread est en deny non apparié ; SYS_mmap est autorisé.

Intégrité

Aucune sur ce reliquat. Les négatifs prouvés en lab ont tous renvoyé errno=22 EINVAL et n'ont pas créé de fichiers :

Méthode + sink	Résultat
SYS_open O_RDWR	EINVAL
SYS_open O_CREAT	EINVAL, aucun fichier créé
SYS_openat même avec O_RDONLY	EINVAL
SYS_execve	EINVAL
socket, ptrace	EINVAL (deny non apparié supplémentaire)

openat / openat2 / creat / unlink / chmod restent en deny non apparié sur ce pin.

Disponibilité

Pas dans le périmètre.

Ce que ce reliquat n'accorde pas

• Écriture hôte, exec, ptrace, process_vm_readv, io_uring_setup, bpf, mount, pivot_root, unshare, setns, connect, ioctl, getdents
• x32 / i386 : seccompiler 0.5.0 préfixe AUDIT_ARCH_X86_64 ou KILL_PROCESS
• clone3 hérite du filtre ; écrire uid_map nécessite un open bloqué
• Le FS virtuel invité (in_mem + tar_ro) est inchangé. Ce reliquat concerne le VFS hôte via un véritable syscall
• Le userland Windows n'a pas de seccomp ; ce runner ne revendique pas cette frontière
• Pas de RCE, pas de LPE, pas d'évasion de bac à sable vers un autre UID

Comment je l'ai trouvé

J'ai épinglé microsoft/litebox v0.1.0 (d8556e3, 2026-10-07) plutôt que main. Dix-huit recherches dans les sources. Le crate du réécrivain et GitHub #1006 disent déjà que les trampolines ne sont pas la frontière. Le filtre Linux userland l'est. SYS_open avec les flags 0 est présent pour que CoW puisse réouvrir le fichier programme. Il n'y a aucune vérification de chemin.

Fausse piste : Docker Desktop Rosetta et qemu-user-static refusent tous deux seccomp(SET_MODE_FILTER) sur cet hôte (EINVAL / ENOSYS). Le lab démarre donc un noyau virt Alpine x86_64 sous qemu-system-x86_64 TCG et exécute le filtre copié en tant que PID 1 afin que le BPF atteigne un véritable noyau x86_64. Règles seccompiler 0.5.0 copiées, pas un appel enable_seccomp_filter in-tree, et pas le workspace complet.

Lab

cd lab
./run.sh

Loopback 127.0.0.1:19110. Projet Compose litebox-seccomp-open-rdonly. Plateforme linux/amd64. Témoin LITEBOX-SECCOMP-OPEN-RDONLY-WITNESS. Dernière ligne :

SUCCESS litebox-seccomp-open-rdonly open-rdonly-ok rdwr-einval openat-einval execve-einval LITEBOX-SECCOMP-OPEN-RDONLY-WITNESS

Correctif

Retirer SYS_open du filtre et pré-ouvrir les FD CoW avant PR_SET_SECCOMP, ou ajouter un prédicat de chemin qui ne peut pas voir les chemins hôtes en dehors du FS invité. Le deny non apparié couvre déjà openat.

Le canal de réception du fournisseur est MSRC (https://msrc.microsoft.com/create-report). N'ouvrez pas d'issue GitHub publique sur microsoft/litebox.

Contact

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