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

litebox-seccomp-open-rdonly

Klasse: Dateilesen (Sandbox-Dateisystemgrenze) Reichweite: Lokal

LiteBox v0.1.0 (d8556e3) - Microsoft

Der dokumentierte Linux-Userland-Runner (litebox-runner-linux-userland) installiert einen Deny-by-Default-Seccomp-Filter und lädt dann ein Gast-ELF im selben Prozess. SYS_open steht auf der Allowlist, wenn Argument 1 (Flags) ein Dword gleich OFlags::RDONLY (0) ist. Es gibt kein Pfad-Prädikat. Ein Gast, der einen echten syscall mit Flags 0 absetzt, öffnet das Host-VFS als Runner-UID und liest dann diese Bytes per read / mmap. Der ELF-Rewriter ist bei diesem Pin keine Sicherheitsgrenze. --rewrite-syscalls ist -Z und standardmäßig aus.

Dieser Überrest ist Host-Dateisystem-Lesen. Er ist kein Host-Schreiben, kein Exec, kein Ptrace, kein LPE und kein RCE.

ID	noch keine CVE
Klasse	Dateilesen (Sandbox-Dateisystemgrenze)
Reichweite	Lokal (nicht vertrauenswürdiges Gast-Binary im Runner-Prozess)
CWE	CWE-284, CWE-862
CVSS	Hoch: 7.1 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Produkt	microsoft/litebox
Betroffen	v0.1.0 (d8556e33676e47244bfefa139c1e9ff95bd67d53) Linux-Userland-Plattform + Runner
Auth	Gast läuft bereits innerhalb der Sandbox
Lizenz	GNU Affero GPL v3.0
Lab	nur 127.0.0.1, linux/amd64

Was ein Angreifer tun kann

Wer: ein nicht vertrauenswürdiges Gast-Binary in litebox-runner-linux-userland. Der Hersteller (CvvT auf GitHub #1006) und die Doku des Rewriter-Crates sagen, dass ELF-Trampoline keine Sicherheitsgrenze sind. Die Linux-Userland-Sicherheit ist dieser Filter. enable_seccomp_filter ist Deny-by-Default (Errno(EINVAL) im Release) mit TSYNC und PR_SET_NO_NEW_PRIVS. Das Loch ist SYS_open mit Flags Eq 0 ohne Pfadprüfung. Der Kommentar in page_mgmt.rs besagt, dass das CoW-Mapping die Host-Programmdatei erneut öffnet, nachdem der Filter aktiv ist, statt einen vorab geöffneten FD zu halten.

Recon (im Lab nachgewiesen)

Methode + Sink	Privileg
echtes SYS_open("/oracle/secret", 0) dann SYS_read	Host-Datei-Bytes, die die Runner-UID lesen kann. Lab: fd 3, 35 Bytes, Witness LITEBOX-SECCOMP-OPEN-RDONLY-WITNESS. Der Pfad ist das Initramfs-Host-VFS, nicht das Gast-Overlay.

Recon (aus demselben Filter abgeleitet; nicht das Lab-Orakel)

Methode + Sink	Privileg
SYS_open("/etc/passwd", 0) dann read / mmap	weltweit lesbare Host-Dateien als Runner-UID
SYS_open von Runner-eigenen Pfaden (SSH-Keys, .env, Kubeconfig, Cloud-Credentials, --initial-files-Tar)	diese Bytes, wenn die UID sie öffnen kann
SYS_open("/etc/shadow", 0)	Shadow-Hashes nur wenn der Runner root ist
SYS_open("/proc/self/maps", 0)	Runner-Maps, einschließlich Host-.text / libc (derselbe Prozess)
SYS_open("/proc/self/mem", 0) dann mmap des FD	Runner-Adressraum, den die UID über procfs lesen kann. pread ist unmatched deny; SYS_mmap ist erlaubt.

Integrität

Keine bei diesem Überrest. Im Lab nachgewiesene Negativfälle gaben alle errno=22 EINVAL zurück und erzeugten keine Dateien:

Methode + Sink	Ergebnis
SYS_open O_RDWR	EINVAL
SYS_open O_CREAT	EINVAL, keine Datei erzeugt
SYS_openat selbst mit O_RDONLY	EINVAL
SYS_execve	EINVAL
socket, ptrace	EINVAL (zusätzliches unmatched deny)

openat / openat2 / creat / unlink / chmod bleiben unmatched deny bei diesem Pin.

Verfügbarkeit

Nicht in der Leiste.

Was dieser Überrest nicht gewährt

• Host-Schreiben, Exec, Ptrace, process_vm_readv, io_uring_setup, bpf, mount, pivot_root, unshare, setns, connect, ioctl, getdents
• x32 / i386: seccompiler 0.5.0 präfixt AUDIT_ARCH_X86_64 oder KILL_PROCESS
• clone3 erbt den Filter; das Schreiben von uid_map benötigt ein blockiertes open
• Gast-virtuelles Dateisystem (in_mem + tar_ro) ist unverändert. Dieser Überrest ist Host-VFS über einen echten Syscall
• Windows-Userland hat kein seccomp; dieser Runner beansprucht diese Grenze nicht
• Kein RCE, kein LPE, kein Sandbox-Escape zu einer anderen UID

Wie ich es gefunden habe

Ich habe microsoft/litebox v0.1.0 (d8556e3, 2026-10-07) gepinnt statt main. Achtzehn Quellcode-Suchen. Das Rewriter-Crate und GitHub #1006 sagen bereits, dass Trampoline nicht die Grenze sind. Der Linux-Userland-Filter ist es. SYS_open mit Flags 0 ist dort, damit CoW die Programmdatei erneut öffnen kann. Es gibt keine Pfadprüfung.

Irrweg: Docker Desktop Rosetta und qemu-user-static verweigern beide seccomp(SET_MODE_FILTER) auf diesem Host (EINVAL / ENOSYS). Das Lab bootet daher einen x86_64-Alpine-Virt-Kernel unter qemu-system-x86_64 TCG und führt den kopierten Filter als PID 1 aus, damit das BPF auf einen echten x86_64-Kernel trifft. Kopierte seccompiler-0.5.0-Regeln, kein In-Tree-enable_seccomp_filter-Aufruf und nicht der vollständige Workspace.

Lab

cd lab
./run.sh

Loopback 127.0.0.1:19110. Compose-Projekt litebox-seccomp-open-rdonly. Plattform linux/amd64. Witness LITEBOX-SECCOMP-OPEN-RDONLY-WITNESS. Letzte Zeile:

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

Fix

SYS_open aus dem Filter entfernen und die CoW-FDs vor PR_SET_SECCOMP vorab öffnen, oder ein Pfad-Prädikat hinzufügen, das keine Host-Pfade außerhalb des Gast-Dateisystems sehen kann. Unmatched deny deckt openat bereits ab.

Die Hersteller-Meldung erfolgt über MSRC (https://msrc.microsoft.com/create-report). Öffnen Sie kein öffentliches GitHub-Issue zu microsoft/litebox.

Kontakt

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