runwasi facilitates running Wasm and WASI workloads managed by containerd

Why it is Amber

• CVSS 9.3 critical
• Remotely exploitable without logging in
• On your watchlist: containerd

References

• https://github.com/containerd/runwasi/commit/d28ab73c2c8a6c50d1927078821bd418b9e51638
• https://github.com/containerd/runwasi/releases/tag/containerd-shim-wasmtime/v0.6.1
• https://github.com/containerd/runwasi/security/advisories/GHSA-cc25-vq59-rcjx

Original description

runwasi facilitates running Wasm and WASI workloads managed by containerd. Prior to 0.6.1, containerd-shim-wasmtime-v1 can treat Wasmtime precompiled bytes supplied directly in an OCI image layer as a trusted artifact from the precompile-cache path and deserialize them as native code. An attacker who causes a victim to run a crafted image can bypass WebAssembly validation and execute native code in the shim zygote process, gaining the filesystem, environment, credentials, networking, and Linux syscall access available to the workload container. Downstream shims built with runwasi's containerd-shim-wasm precompile-cache API are also affected if they implement Compiler and trust executable precompiled artifacts from OCI image layers; the 0.6.1 boundary applies specifically to containerd-shim-wasmtime and does not independently certify downstream product releases. The flaw escapes the WASI sandbox to the workload container boundary, but it does not by itself bypass container isolation or provide direct host code execution. This issue is fixed in version 0.6.1.