[Bug Report] Super-critical Project — Unauthorized Access Vulnerability in Container’s mount_fd Usage

[LYNXRAYAI]

Summary

The rustjail container startup flow appears to accept mount namespace paths from the OCI spec and later use the resulting file descriptor with setns. If an attacker-controlled spec can provide a host mount namespace path, the sandboxed process may join the host mount namespace and break sandbox isolation.

Affected Component

Relevant component:

• agent / rustjail

Affected files:

• agent/rustjail/src/container.rs
• agent/rustjail/src/validator.rs

Description

The reviewed reports indicate that container.rs opens namespace paths from linux.namespaces and later calls sched::setns(mount_fd, CloneFlags::CLONE_NEWNS) for the mount namespace.

The validation logic in validator.rs appears to check for the presence of a mount namespace, but does not restrict the mount namespace path itself. This may allow a malicious OCI spec to reference an existing host mount namespace, causing the sandboxed process to join it.

Please see the linked reports for the detailed data-flow, code references, and reproduction details.

Expected Behavior

The runtime should not allow untrusted OCI specs to provide arbitrary mount namespace paths.

Mount namespace paths should either be rejected for untrusted specs or strictly limited to trusted runtime-managed namespaces.

Actual Behavior

According to the reports, the mount namespace path is opened directly and the resulting file descriptor is used with setns without sufficient validation.

Security Impact

If exploitable, this can allow a sandboxed process to join the host mount namespace, exposing the host filesystem mount view and breaking filesystem isolation. This may lead to host file access and broader sandbox escape.

Suggested Remediation

• Reject non-empty mount namespace paths for untrusted OCI specs.
• Restrict namespace paths to trusted runtime-managed locations.
• Validate namespace file descriptors before calling setns.
• Explicitly block host namespace paths such as /proc/<pid>/ns/mnt.
• Add regression tests for malicious mount namespace paths.

Additional Context

Detailed reports:

• Super-critical Project — Unauthorized Access Vulnerability in Container’s mount_fd Usage: https://sec.transplane.sg/share/reports/aeBFkdTnStelDwmqXIzbwyiPw42mjh-p
• Super‑Critical Project – mount_fd setns vulnerability in container.rs leads to mount namespace leakage: https://sec.transplane.sg/share/reports/L7nGpEEXsjH1XL5JqFrrHxb97qR8NHzk

[fslongjin]

Thanks for the report.

We reviewed the referenced code path and agree that linux.namespaces[*].path for type: "mount" is currently not
explicitly rejected before rustjail opens the namespace path and later calls setns(CLONE_NEWNS).

However, the report appears to assume that /proc/1/ns/mnt inside the agent/runtime environment is the physical host
mount namespace. In CubeSandbox, the agent runs inside the sandbox guest/MicroVM, so /proc/<pid>/ns/mnt should refer
to namespaces inside the guest, not the node host outside the KVM boundary. Based on the current evidence, this looks
like a possible guest-internal container/rootfs isolation issue, but not yet a demonstrated Cube host escape.

Could you please provide a working PoC and the exact environment used, including:

• how the malicious OCI spec was injected into CubeSandbox;
• the exact linux.namespaces section used;
• the observed readlink /proc/self/ns/mnt before and after container start;
• evidence that files outside the MicroVM/guest boundary were accessed, if the claim is host escape;
• CubeSandbox version/commit and deployment mode.

Without a concrete PoC showing the namespace transition and host-side impact, we cannot validate the claimed critical
severity or the “host filesystem access” conclusion.

We will continue evaluating whether non-empty mount namespace paths should be rejected defensively, but for now the
report needs reproduction evidence to confirm exploitability and impact.

Once you have successfully reproduced this issue in a real environment and confirmed it is a genuine security vulnerability, please send the security report to jinlong@tencent.com or coolli@tencent.com, and we will further evaluate the issue.