Firecracker runs each microVM with a tiny device set: virtio-block, virtio-net, virtio-vsock, a serial console, a minimal interrupt controller, and a few platform devices, nothing else. It is written in Rust and shipped with a jailer that wraps each instance in a seccomp filter, a chroot, and dedicated namespaces and cgroups. The guest-to-host escape surface is therefore narrow: the virtio devices and their virtqueue handling. The host-side surface is the REST control API (on a Unix socket) and the jailer's confinement, where a weak configuration or a logic flaw in device or API handling is the realistic target rather than a classic memory-corruption bug.
The surfaces#
# guest side: the only paravirtual devices present
lspci 2>/dev/null; ls /sys/bus/virtio/devices 2>/dev/null # virtio-mmio block/net/vsock
# host side: the control API socket (per microVM)
curl --unix-socket /run/firecracker.socket -s http://localhost/machine-config
Escape and abuse surface:
- virtio-block / -net / -vsock virtqueue descriptor handling (the only device parsing)
- the vsock device, which bridges guest and host sockets, is a notable logic surface
- the REST API: whoever reaches the control socket can reconfigure/boot/stop the VM,
attach drives (host files), and set up networking - control of the microVM
- the jailer: if the seccomp profile, chroot, or namespaces are weakened or bypassed,
a device-layer bug that would be contained becomes a broader host compromise
Exploitation notes#
- The virtio virtqueue handling is the guest-to-host surface; the mechanisms match virtio devices, but the implementation is Rust, so the realistic bugs are logic errors and
unsafeblocks rather than ubiquitous overflows. - vsock is a distinctive surface because it bridges guest sockets to host sockets; its connection and buffer handling is a logic-flaw target.
- The REST API socket is effectively microVM control: reaching it lets an attacker attach host files as drives or reconfigure the VM, so its access control (socket permissions, the jailer) is critical.
- The jailer's seccomp, chroot, and namespace confinement is the defense-in-depth layer; its strength determines whether a device-layer compromise stays contained, so assess the jailer configuration.