This is a result of an internal vuln finding run. Many of these are known issues, but don't appear to have tracking issues, so I'm filing them anyway.

[Security] Unvalidated CDI Host Mounts & RuntimeAssetPaths in ateom

Severity: HIGH (4.50) | CWE: CWE-250 / CWE-73

Problem Description

In ateom-microvm and ateom-gvisor, paths provided in RuntimeAssetPaths and Container Device Interface (CDI) device injections are executed as root or mounted from the host without rigorous validation:

1. ateom-microvm executes binary paths provided in RuntimeAssetPaths (cloud-hypervisor, virtiofsd, kernel) as root without verifying they reside inside a read-only trusted directory (cmd/ateom-microvm/run.go:730, cmd/ateom-microvm/restore.go:315).
2. ateom-gvisor's cdiinject injects CDI HostPath mounts and follows symlinks when reading ELF headers on the host (cmd/ateom-gvisor/internal/cdiinject/inject.go:121, cmd/ateom-gvisor/internal/cdiinject/soname.go:37).

Attack Vector

An attacker with control over microvm asset paths or CDI specifications can:

1. Supply arbitrary host executable paths in RuntimeAssetPaths, causing ateom to execute arbitrary host binaries with root privileges.
2. Specify arbitrary host paths in CDI device definitions to mount sensitive host directories into the container or cause host file leakage via symlink resolution.

Impact

Arbitrary code execution as root on the worker host node, host directory traversal, and MicroVM container breakout.

Proposed Remediation

1. Validate and strictly constrain RuntimeAssetPaths to verified, trusted root directories; reject relative paths or unverified targets.
2. In cdiinject, validate HostPath mounts against an allowlist and ensure symlinks are safely evaluated without escaping root device paths.
3. Add automated tests verifying that invalid asset paths and arbitrary host paths in CDI specs are rejected.