I really wish they would have expanded on this paragraph in their article further:

> 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.

▲

tptacek 11 hours ago | parent | next [-]

That's a good catch. Yes, since they've only proven this up to the jailer boundary, you'd need a second and relatively powerful LPE vulnerability to get real host control out of this.

▲

rvz 8 hours ago | parent [-]

Thanks to frontier reasoning agents, Linux is completely riddled in ways you can discover 900+ LPE vulnerabilities. [0]

Another wave of vulnerabilities like this are yet to be discovered in Linux. We are just seeing how weak C and C++ based OSes and kernels are when put under hundreds of AI agents.

[0] https://openai.com/index/a-thousand-fewer-paths-to-root/

▲

rockskon 6 hours ago | parent | next [-]

And how many of these vulns are in code for legacy hardware or filesystem support that in no way reflects threats against modern Linux installs? I wager the overwhelming majority of them.

	▲	wahern 5 hours ago \| parent [-]
		The recent OpenAI release linked above targeted only ~3M SLoC (out of ~40M), core systems code reachable from within a simple VM guest.

▲

devmor 6 hours ago | parent | prev [-]

We always knew this, it has been understood since nearly the dawn of the monokernel OS that there is always a route to privilege escalation somewhere. This is why even for web applications that would be better served by a shell, people choose CGI-style interfaces instead.

The only reason it wasn't seen as a problem was due to the effort and time it took to find and exploit them.

▲

sscaryterry 9 hours ago | parent | prev | next [-]

> 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".

▲

tclancy 8 hours ago | parent [-]

Hang on, what are you getting at?

▲

sscaryterry 7 hours ago | parent [-]

They ran it without a jailer, and exploited a bug in the linux socket code. Firecracker was just how they invoked/worked with /dev/kvm. It is not a firecracker bug. Its sensationalist nonsense.

▲

tptacek 7 hours ago | parent [-]

It's very much a Firecracker thing. KVM is part of the Firecracker stack, and getting code execution behind the jailer is still effectively game-over; it's just a somewhat higher degree-of-difficulty game-over. It's a drastically worse place than you would have been last year, when there wasn't a known plausible way to get even that far.

This is a really good bug and nobody should downplay it.

▲

roughly 4 hours ago | parent | next [-]

Huh, so the assertion here that this is a break past the KVM boundary broadly, then?

Also - re: the jailer, do you have more info on that being popped?

▲

catlifeonmars 4 hours ago | parent | prev | next [-]

GP said

> They ran it without a jailer

And you said

> getting code execution behind the jailer is still effectively game-over

So I’m really confused, which is it?

▲

tptacek 4 hours ago | parent [-]

Both, maybe? I mean: whether or not they broke the jailer, we know the jailer is breakable; it wouldn't really even be newsworthy to have an LPE that breaks the Firecracker jailer.

	▲	stogot 4 hours ago \| parent \| next [-]
		Did they break the jailer? I thought from these comments they disabled it. then the breach happens in KVM? Isn’t KVM its own software repo, and firecracker sits on top? How is this firecracker and not a KvM thing
	▲	tclancy 3 hours ago \| parent \| prev [-]
		I deeply love my idiot comment about not using password for your password generated useful stuff. Kudos to everyone here who rescued my idiocy. Now to change my luggage combination.

▲

zobzu 3 hours ago | parent | prev [-]

sounds like saying it's a Ubuntu thing because you can install firecracker and use kvm to me.

the truth is there plenty more kvm escapes that will be found.

▲

vluft 10 hours ago | parent | prev | next [-]

yup, the other firecracker escape recently (https://www.coinspect.com/blog/firecracker-escape/) popped the jailer via io_uring (tl;dr firecracker was filtering syscalls appropriately with seccomp, and was filtering the uring _they_ initiated, so attacker just got them to pop a new unfiltered uring, which is rather nice).

▲

tptacek 9 hours ago | parent [-]

Just for what it's worth, that escape is much more situational than PwnEscape (there have been other escapes that depended on nested KVM, as well). Pretty much everyone seems to have been exposed with PwnEscape, because everyone using Firecracker is also using virtio-net.

	▲	a32patt23qfpatt 7 hours ago \| parent [-]
		[dead]

▲

amluto 10 hours ago | parent | prev [-]

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 10 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 5 hours 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 8 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 7 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 6 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.

	▲	whiatp 3 hours ago \| parent [-]
		I was reading through and thought "surely I missed a step here" in more than one place. They mention in part 1 having a write primitive that can hit a 64 byte region, but never really explained how that worked. I'm guessing this was them being able to have checksum offload write TCP/UDP checksum values into the overhang region past the valid data. Maybe the memory map was set up that way, but obviously relies on getting really lucky with getting their page table in the next page after their packet. Also it was never called out, but as far as I can tell their exploit should only be able to target the beginning of pages for reading/writing. In order to rug-pull the socket logic that reads the IP IHL field, the IP header content needs to be in a page mapped to the guest. The only useful way to use this attack is to have the region spill out of the guest page into whatever page comes next in the kernel's memory map. (Which also makes the mentioning of the skb linear header kind of confusing, since that would be in a completely unrelated kernel memory region, and just have the data pointers pointing into their data, which is what happens for zero-copy network drivers, which presumably was set up for the kvm network for them to retain guest control over the packet.)