Firecracker VM Escape: PwnEscape Part 2
https://pwn.ai/blog/firecracker-escape> 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.
Exactly, its not a firecracker issue. Using firecracker without a jailer is like setting your password to "password".
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.
This is different from KVM where your hypervisor runs in your Dom0/Root Partition.
To save people the time:
"This code is experimental and not feature complete. If it breaks, you get to keep both pieces."
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.
> "run SQL against 110+ databases"
I work on connectors for datasources (mostly DB's. Being able to quickly test things like sorting behavior and how the same function can be emulated across DB's would have made my life so much easier.
Does this mean you ran the exploit on your service and confirmed it worked? If so, why would you be advertising this, lol. Unless you've already patched?
Couldn't find it. Care to provide link.
(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.