Firecracker, a lightweight virtualization engine designed to isolate untrusted code in microVMs, has been compromised by researchers who achieved code execution as root on the underlying host system.
According to a detailed technical writeup from pwn.ai, the attack exploits a memory access vulnerability to break out of the guest and take control of the Firecracker process itself. The researchers found how Firecracker saves CPU registers when entering KVM, modified where the thread would resume execution, and made it call attacker-chosen code upon returning from the KVM syscall. Remarkably, Firecracker continued running afterward and the VM remained accessible over SSH, demonstrating a silent compromise.
The Attack Chain
The exploit works in stages. First, researchers used a previously disclosed host memory primitive to place a recognizable byte pattern in a guest page, then searched the host’s physical memory to locate that page. Extended Page Tables (EPT), which translate guest physical addresses to host physical addresses, provided the pathway.
Once the guest page was located in host memory, the team worked backward to find the Firecracker process itself. They searched host page tables for mappings of the guest page, recovered the virtual address and page table root (PGD) belonging to Firecracker, and validated it by locating the Firecracker binary’s ELF header and checking known byte sequences in its write syscall wrapper.
With the Firecracker process identified, researchers calculated its address space layout randomization (ASLR) load bias—the runtime offset of the executable—and pinpointed three critical code locations: the write wrapper for producing proof of execution, the continuation point after the KVM ioctl syscall, and a xor eax,eax; ret gadget.
Hijacking the vCPU Thread
The final stage involved locating the saved register frame of the host thread running the guest’s virtual CPU. When a vCPU thread executes KVM_RUN, the kernel stores its registers in a pt_regs structure. The researchers identified this frame by checking that its saved instruction pointer matched the KVM ioctl continuation in Firecracker, that its stack pointer translated to valid host memory, and that its syscall fields indicated an active KVM_RUN operation.
Once located, the saved registers were modified to redirect execution to attacker-controlled code. When the thread returned from KVM, it executed the malicious code with the privileges of the Firecracker process, which has root access to the host.
The researchers note this continues work from PwnEscape Part 1, which introduced the initial host memory primitive enabling the attack.
Key facts
- Researchers escaped Firecracker microVM and achieved root code execution on the host system
- The attack modifies saved CPU registers to redirect a vCPU thread when it returns from KVM
- Firecracker process was identified by tracing guest memory pages backward through host page tables
- The exploit required locating the Firecracker binary’s load bias to bypass ASLR
- The VM remained operational and accessible after the hijack, demonstrating a silent compromise