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/
I’m not sure the people that caused this will be the one fixing it.
The only reason it wasn't seen as a problem was due to the effort and time it took to find and exploit them.
Exactly, its not a firecracker issue. Using firecracker without a jailer is like setting your password to "password".
This is a really good bug and nobody should downplay it.
Also - re: the jailer, do you have more info on that being popped?
> 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?
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
the truth is there plenty more kvm escapes that will be found.
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.
Which like, isn't really a proof of concept of anything being described.
"That was always allowed".
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.
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.)