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

litebox-seccomp-open-rdonly

Classe: Leitura de arquivo (fronteira de FS do sandbox) Alcance: Local

LiteBox v0.1.0 (d8556e3) - Microsoft

O runner documentado de userland Linux (litebox-runner-linux-userland) instala um filtro seccomp deny-by-default e, em seguida, carrega um ELF convidado no mesmo processo. SYS_open está na allowlist quando o argumento 1 (flags) é um dword igual a OFlags::RDONLY (0). Não há predicado de caminho. Um convidado que emite um syscall real com flags 0 abre o VFS do host com o UID do runner e, em seguida, faz read / mmap desses bytes. O reescritor de ELF não é uma fronteira de segurança neste pin. --rewrite-syscalls é -Z e desativado por padrão.

Este resíduo é leitura do FS do host. Não é escrita no host, não é exec, não é ptrace, não é LPE e não é RCE.

ID	sem CVE ainda
Classe	Leitura de arquivo (fronteira de FS do sandbox)
Alcance	Local (binário convidado não confiável no processo do runner)
CWE	CWE-284, CWE-862
CVSS	Alto: 7.1 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Produto	microsoft/litebox
Afetado	v0.1.0 (d8556e33676e47244bfefa139c1e9ff95bd67d53) plataforma userland Linux + runner
Autenticação	convidado já em execução dentro do sandbox
Licença	GNU Affero GPL v3.0
Lab	somente 127.0.0.1, linux/amd64

O que um atacante pode fazer

Quem: um binário convidado não confiável em litebox-runner-linux-userland. O fornecedor (CvvT no GitHub #1006) e a documentação do crate do reescritor dizem que trampolins de ELF não são uma fronteira de segurança. A segurança do userland Linux é este filtro. enable_seccomp_filter é deny-by-default (Errno(EINVAL) em release) com TSYNC e PR_SET_NO_NEW_PRIVS. O furo é SYS_open com flags Eq 0 sem verificação de caminho. O comentário em page_mgmt.rs é que o mapeamento CoW reabre o arquivo do programa host depois que o filtro está ativo, em vez de manter um FD pré-aberto.

Recon (comprovado em lab)

Método + sink	Privilégio
SYS_open("/oracle/secret", 0) real e depois SYS_read	Bytes de arquivo do host que o UID do runner pode ler. Lab: fd 3, 35 bytes, testemunha LITEBOX-SECCOMP-OPEN-RDONLY-WITNESS. O caminho é o VFS do host do initramfs, não o overlay do convidado.

Recon (inferido do mesmo filtro; não é o oráculo do lab)

Método + sink	Privilégio
SYS_open("/etc/passwd", 0) e depois read / mmap	arquivos do host legíveis por todos como UID do runner
SYS_open de caminhos pertencentes ao runner (chaves ssh, .env, kubeconfig, credenciais de nuvem, tar de --initial-files)	esses bytes se o UID puder abri-los
SYS_open("/etc/shadow", 0)	hashes do shadow somente se o runner for root
SYS_open("/proc/self/maps", 0)	mapas do runner, incluindo .text do host / libc (mesmo processo)
SYS_open("/proc/self/mem", 0) e depois mmap do FD	espaço de endereçamento do runner que o UID pode ler via procfs. pread é deny não correspondido; SYS_mmap é permitido.

Integridade

Nenhuma neste resíduo. Negativas comprovadas em lab retornaram todas errno=22 EINVAL e não criaram arquivos:

Método + sink	Resultado
SYS_open O_RDWR	EINVAL
SYS_open O_CREAT	EINVAL, nenhum arquivo criado
SYS_openat mesmo com O_RDONLY	EINVAL
SYS_execve	EINVAL
socket, ptrace	EINVAL (deny extra não correspondido)

openat / openat2 / creat / unlink / chmod permanecem deny não correspondido no pin.

Disponibilidade

Não está no bar.

O que este resíduo não concede

• Escrita no host, exec, ptrace, process_vm_readv, io_uring_setup, bpf, mount, pivot_root, unshare, setns, connect, ioctl, getdents
• x32 / i386: seccompiler 0.5.0 prefixa AUDIT_ARCH_X86_64 ou KILL_PROCESS
• clone3 herda o filtro; escrever uid_map precisa de um open bloqueado
• O FS virtual do convidado (in_mem + tar_ro) permanece inalterado. Este resíduo é o VFS do host via syscall real
• O userland Windows não tem seccomp; esse runner não reivindica esta fronteira
• Não é RCE, não é LPE, não é uma fuga do sandbox para outro UID

Como eu encontrei

Fiz o pin de microsoft/litebox v0.1.0 (d8556e3, 2026-10-07) em vez de main. Dezoito buscas no código-fonte. O crate do reescritor e o GitHub #1006 já dizem que trampolins não são a fronteira. O filtro do userland Linux é. SYS_open com flags 0 está lá para que o CoW possa reabrir o arquivo do programa. Não há verificação de caminho.

Caminho errado: Docker Desktop Rosetta e qemu-user-static recusam ambos seccomp(SET_MODE_FILTER) neste host (EINVAL / ENOSYS). O lab, portanto, inicializa um kernel virt Alpine x86_64 sob qemu-system-x86_64 TCG e executa o filtro copiado como PID 1 para que o BPF atinja um kernel x86_64 real. Regras copiadas do seccompiler 0.5.0, não uma chamada enable_seccomp_filter in-tree, e não o workspace completo.

Lab

cd lab
./run.sh

Loopback 127.0.0.1:19110. Projeto Compose litebox-seccomp-open-rdonly. Plataforma linux/amd64. Testemunha LITEBOX-SECCOMP-OPEN-RDONLY-WITNESS. Última linha:

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

Correção

Remova SYS_open do filtro e pré-abra os FDs do CoW antes de PR_SET_SECCOMP, ou adicione um predicado de caminho que não consiga ver caminhos do host fora do FS do convidado. O deny não correspondido já cobre openat.

O encaminhamento ao 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]