Hacker News Reader

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.

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/

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.

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.

The recent OpenAI release linked above targeted only ~3M SLoC (out of ~40M), core systems code reachable from within a simple VM guest.

Watch Hartman’s response to the first wave of issues found by AI. Super dismissive and ignorant.

I’m not sure the people that caused this will be the one fixing it.

you sure the people who caused this (speeding up Linux to mainly serve ads instead of hardening it?) aren't the exact same people now pushing the antidote?

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.

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.

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

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.

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.

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

The malware infection has been identified as Clang, part of the LLVM threat actor. To clear this infection unlink the directories named /dev and /proc on Ubuntu.

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.

Thanks! This makes sense. It also, of course, makes the jailer irrelevant; just find a non-jailed process to inject into.

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

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.

I actually do use Firecracker without a network adapter, though vsock/virtio could have remaining issues

Sure, sorry, I meant providers --- all the providers are using virtio-net.

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

Hang on, what are you getting at?

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.

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.

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?

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.

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

They C debugging APIs and root permissions in the Host OS to exploit a user mode process in the Host OS. Fire is hot. Water is wet.

The jailer doesn't give you debugging APIs to work with. Jailed, if your original exploit only gives you RCE in Firecracker itself, you still need another LPE vulnerability to break the sandbox.

If they have arbitrary code execution in the Linux kernel itself (which it feels like maybe they should?) then the jailer is a nonfactor. But the exploit they write up sure seems like it's just getting code execution in userland from Firecracker itself.

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.

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?

The jailer is just a seccomp sandbox. It's not a novel defense system. Sandboxes get broken all the time.

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.

I'm sure there will be! They've been extremely rare to date, because KVM is itself a relatively simple piece of code, but everything's up for grabs now.