← Back to archive
KL-2025-002VERIFIEDHighRuntime Isolation

Infrastructure processes fully ptraceable from guest workload

Firecracker microVM · AI sandbox runtime

Observed: 2025

Guest workloads inside a Firecracker-based AI sandbox were able to enumerate, inspect, and attach to infrastructure processes responsible for orchestration and storage bridging. Yama LSM was absent. PID, mount, user, and network namespaces were shared between the workload and infrastructure processes — meaning there was no process-level isolation boundary inside the guest.

Environment

PlatformFirecracker-based AI sandbox
AccessStandard user-facing interface
MethodProcess enumeration, ptrace testing
TestingControlled

Key Findings

  • ●ptrace(PTRACE_ATTACH) succeeded against PID 1
  • ●/proc/[pid]/maps fully readable
  • ●Shared PID, mount, user, network namespaces
  • ●Yama ptrace_scope set to 0

Evidence

ptrace(PTRACE_ATTACH, 1) = 0
PTRACE_GETREGS: success
process_vm_readv: not blocked

/proc/1/maps: readable
/proc/1/fd/4: socket:[12834]
/proc/1/fd/7: /session/output (FUSE handle)

/proc/sys/kernel/yama/ptrace_scope: 0

Security Implication

A compromised workload can inspect the runtime memory of orchestration components, read open file descriptors including FUSE handles and sockets, and in the worst case terminate or corrupt infrastructure processes. In a multi-tenant or high-value AI deployment this represents a meaningful escalation path from workload compromise to infrastructure interference.

Remediation

1Namespace-separate infrastructure and workload processes
2Enable Yama ptrace restrictions (ptrace_scope = 1 or 2)
3Run orchestration processes under a separate UID
4Restrict /proc visibility using hidepid mount options

Disclosure Status

Vendor notified

No

Disclosure type

Public research

Exploit achieved

No