Nope. The exploit compromises the host kernel. The researchers built an unconventional exploit chain in which they used the host kernel compromise to compromise the host firecracker userspace code, but I see no fundamental reason they couldn't have compromised something else in the host kernel.

▲

tptacek 6 hours ago | parent [-]

Wait, this is also presumably true, come to think of it. I'm a little fuzzy because they document the memory disclosure primitive carefully but not the memory writes they also got from it --- but whatever those are, they're hitting kernel memory? But the exploit they're describing here gets code execution out of Firecracker itself, not the kernel.

▲

amluto an hour ago | parent | next [-]

AIUI they’ve chosen as their target the host userspace pt_regs, i.e. the kernel structure that stores Firecracker’s register state. If they can find it and write to it, they can control the complete register state of Firecracker.

I assume they chose it as their target because Firecracker, like most Linux KVM userspace [0], maps guest memory into its own address space, giving an easy place to write gadgets.

My personal favorite thing to poke into pt_regs is an actual privileged (CPL0) context. [1] Returning from the kernel right back to a controlled kernel context is allowed by the CPU :)

[0] Until fairly recently this was mandatory. These days it’s possible to ask KVM to map something into the guest without having it in host userspace memory.

[1] Corrupt pt_regs so it executes user memory in kernel mode:

https://seclists.org/oss-sec/2015/q3/291

I think this may be my favorite of all exploits I’ve ever written. In fact, I often made a point of not writing interesting exploits for corruption bugs I found, but this one was too much fun to pass up.

▲

monocasa 5 hours ago | parent | prev [-]

Yeah, they're not saying a lot there. And then the proof of concept code is just being passed the physical addresses of the pages they talk about as command line args, and is just opening /dev/mem to do brain surgery on them.

Which like, isn't really a proof of concept of anything being described.

"That was always allowed".

▲

tptacek 3 hours ago | parent [-]

It's a super good bug! I just don't follow the exploitation details all the way. I know more than one cloud provider panic-bounced their fleet in response to it, and I think that was the right call.

	▲	monocasa 2 hours ago \| parent [-]
		There's for sure a real bug. It just bothers me that the proof of concept starts with the assumption that host physical memory is mapped into guest physical memory at 2^39. If you can't talk about the actual exploit yet, I get it , but don't write a blog post with something like that called a "proof of concept" when the code shows no exploit, and you're obviously dancing around the actual novel exploit here in the chain. Just keep it in your pants until the disclosure window.