> The configuration used here had no jailer. Firecracker's production containment includes dropping privileges and restricting the process through namespaces and seccomp. A deployment using those controls requires a separate assessment of the privileges and resources available after compromising its VMM.

If I'm understanding all of this correctly, a properly jailed and configured firecracker instance would greatly reduce the blast radius of this escape, and I feel as though it would have been good for them to explain what jailing and dropping privileges would do to help. I'd hope most production firecracker deployments would be doing this already.

Not saying that this is any less severe and the root issue is not specific to Firecracker, but to a flaw in the kernel's network code -- they just used an insecure firecracker configuration to demonstrate it. However, I feel like some are taking this as a flaw with firecracker when its not. This is an issue in the kernel networking stack.

Do virtualization with a tiny formally verified microkernel and have complex kernels like Linux run underneath instead of letting a huge, complex, and brittle linux kernel and vm ecosystem control the hypervisor layer.

https://hypervisor.org/

It hosts hundreds of database engines - many of them have vulnerabilities, and some of them, like Pandas, are basically open RCEs regardless.

We can PoC the Firecracker VM Escape on that service.

(Doesn't HN usually deduplicate links? I'm confused)

How do people feel about the hardware isolation provided by microVMs versus the stronger end of software isolation techniques like gvisor?

Right now, we put a huge amount of stock in "hardware isolation". If that starts falling to agents to any substantial degree, I wonder whether we might end up leaning more on patchable software isolation, similar to the rise of software RAID (though, in userspace this time).

Running our microVM's inside of a jailed zone, at least gives me some peace of mind.. It's far from perfect, as a zone escape could be lurking.. but at least it's a layer of defense.

This so-called Firecracker exploit never explained how the Guest was able to write to the Host OS's Firecracker user mode process. If the write controlled by the guest to the host was that TCP/IP routing stack Exploit in the host OS's Linux kernel, this Firecracker Exploit is meaningless. The Guest already has unlimited control over the host OS.

I (and anyone) can do this exploit in 2-3 minutes using GDB or Visual Studio's C debugger tool. Freeze process, type new pointers into CPU context snap shot, click resume, Exploit done.