BoxLite Capability-Based Permission Bypass Enabling Read-Only Mount Remounting
BoxLite's read-only mount implementation relies on MS_RDONLY flag applied post-boot rather than kernel-level enforcement, allowing container processes with unrestricted capabilities to remount directories as read-write. This breaks sandbox isolation in scenarios where untrusted code accesses host credentials, configuration, and source code.
CVE References
Affected
Vulnerability Description
BoxLite implements read-only directory isolation by applying the MS_RDONLY mount flag after VM initialization. This is a userspace enforcement mechanism rather than a kernel-enforced security boundary. The root cause is twofold: (1) the underlying libkrun library lacks native read-only mount support via virtiofs, and (2) BoxLite does not drop or restrict Linux kernel capabilities (CAP_SYS_ADMIN, CAP_SYS_CHROOT) within spawned containers. Any process with CAP_SYS_ADMIN can invoke remount syscalls to convert read-only mounts to read-write, completely bypassing the intended isolation.
Proof-of-Concept Significance
This PoC demonstrates a capability-based privilege escalation rather than a kernel exploit. The attack requires only standard POSIX APIs available to unprivileged processes if capabilities remain enabled. In typical BoxLite deployments (AI agents, untrusted code execution), user credentials, Python virtual environments, and application binaries are mounted read-only. The PoC proves that malicious or compromised agent code can modify these assets, enabling post-exploitation persistence and lateral host compromise. Reliability is high—remount operations are stable across kernel versions.
Detection Guidance
System Call Monitoring: Audit/alert on mount() or umount2() syscalls from container processes with flags indicating remount operations (MNT_FORCE, MS_REMOUNT). Log Indicators: Watch for capability-related denials (audit logs) immediately preceding mount syscalls. Monitor dmesg/kernel logs for remount attempts on virtiofs mounts. Process Context: Correlate container process ancestry with unexpected mount syscalls—legitimate workloads rarely remount host directories. File Integrity Monitoring: Deploy FIM on mounted directories; alert on unexpected modifications from container processes. YARA/eBPF: Write eBPF hooks on do_remount_sb() kernel function to intercept remount attempts originating from container namespaces.
Mitigation Steps
Immediate (Workaround): Drop CAP_SYS_ADMIN and CAP_SYS_CHROOT from container security contexts via securityContext.capabilities.drop in pod specs or --cap-drop in docker/cri-o configurations. Implement AppArmor or SELinux policies denying mount-related syscalls. Patching (BoxLite): Upgrade to a patched BoxLite version that enforces read-only mounts via libkrun kernel-level support or applies mandatory MAC policies preventing remount syscalls. Defense-in-Depth: Use bind-mounts with nodev, nosuid, noexec flags. Store sensitive credentials outside mounted volumes; use secrets management (Vault, K8s Secrets) instead. Mount host binaries in immutable or tmpfs-backed read-only overlays.
Risk Assessment
Likelihood of Exploitation: High—the attack requires no special kernel knowledge and can be deployed via Python/Go containers without privilege escalation. Threat Actor Interest: Extreme for AI/ML supply-chain attacks, where compromised model repositories or agent frameworks can modify dependencies or steal credentials. Impact Multiplier: Affects any organization using BoxLite for untrusted workload isolation (SaaS code execution platforms, AI agencies, research sandboxes). Organizations relying on read-only mounts for compliance (PCI-DSS, SOC2 data segregation) face control failures.
Sources